Cloud
Cloud and cluster.One identity graph.
Roles, machine users, access keys, service accounts and the trust between them are the real perimeter of a cloud estate. Trustivan discovers them across AWS and Kubernetes, computes an upper bound of their effective access and finds the trust relationships that connect accounts nobody meant to connect.
Connectors available today: AWS IAM · Kubernetes
Cloud identity types
The identities your cloud mints for you
Each provider has its own nouns. Trustivan reads AWS IAM and Kubernetes into one model, so a role and a service account can be compared, owned and governed alike.
IAM roles & machine users
Roles with trust policies, machine-oriented users with access keys, group membership and inline policy statements
Kubernetes service accounts
ServiceAccounts, RoleBindings and ClusterRoleBindings, and the Deployments, StatefulSets, DaemonSets and CronJobs that run as them
Cross-account trust
Assume-role trust between AWS accounts, drawn as graph edges with the policy statement behind each
Azure & Google Cloud
Service principals, managed identities and Google service accounts — no connector ships for either yet
Cloud risks
Where cloud identity goes wrong
Six failure patterns specific to cloud identities, the signal Trustivan surfaces for each and the honest status of that signal.
Cross-account trust
Trustivan surfacesRoles assumable from another account, drawn as trust edges with the policy statement that grants each
Cross-account admin chains
Trustivan surfacesIdentities that reach a high-impact resource through trust and permission paths — an upper bound, since Deny and conditions are not evaluated
Aging access keys on machine users
Trustivan surfacesAccess keys on machine-oriented IAM users, with age, rotation-overdue and exposure findings — metadata only
Dormant roles
Trustivan surfacesRoles whose last use — reported only by AWS, for roles and access keys — passes the stale threshold while they still hold permissions
Cluster-wide service accounts
Trustivan surfacesServiceAccounts bound to cluster-wide roles, with the workloads that run as them and a count of their token secrets, never read
Subscription-wide managed identities
Planned signalContributor or Owner at subscription scope on a single function or VM — no Azure connector ships yet
How it works
Discover. Resolve. Trace.
Inventory every AWS and Kubernetes identity, compute what it can reach, then trace the paths that cross accounts and environments.
Every role, machine user, service account and binding — normalized across providers
Read-only connectors enumerate identities from each provider's control plane: IAM roles and machine-oriented users with their access keys, trust and group membership; Kubernetes ServiceAccounts, their bindings and the workloads that run as them. Each lands in the inventory with its type, environment, credentials and grants, ready for ownership.
- Credentials tracked as separate objects: access key metadata, never a secret value.
- Workloads linked to identities: the Deployments, StatefulSets, DaemonSets and CronJobs that run as each ServiceAccount.
- Owner from tags and labels, marked declared or inferred, and unknown when neither exists.
Trust, group membership and inline policy resolved into what an identity can reach
A role's permissions are only the beginning. Trust policies say who can become it, and group memberships add more. Trustivan combines trust, membership and inline policy statements into effective access — an upper bound, because managed policy documents are not read and Deny and conditions are not evaluated.
- Used versus granted is a future capability: AWS reports no per-grant use, so unused stays unknown.
- Blast radius on the graph: every resource an identity can reach, with the route to each.
- Stated as an upper bound, so a reviewer knows the real answer can only be narrower.
Find the path from a sandbox to production
Assume-role trust connects accounts that were supposed to be separate. Trustivan follows trust edges across accounts, surfaces the paths that reach high-impact resources and names the policy statement that makes each hop possible.
- Multi-hop paths from a low-value account to a high-value role, with each hop evidenced.
- Trust edges drawn from policy, not from what was assumed — no connector collects AssumeRole events.
- Environment from the connector, so “staging” is the account the connector covers, not what a role is called.
Integration coverage
Cloud connectors, labelled honestly
Platform names are used nominatively. AWS IAM and Kubernetes ship today; every other name here is planned.
View all integrations- AWS IAMRoles, machine users, access-key metadata, trust, inline policy statementsAvailable
- KubernetesService accounts, role bindings, workloads that run as themAvailable
- Amazon S3Bucket policies, access points, reachabilityPlanned
- AWS Secrets ManagerSecrets, rotation status, resource policiesPlanned
- Azure / Entra IDService principals, app registrations, managed identities, role assignmentsPlanned
- Azure Key VaultSecrets, keys, certificates, access policiesPlanned
- BigQueryDataset IAM, service-account accessPlanned
- GCP Secret ManagerSecrets, versions, IAM bindingsPlanned
- Google Cloud IAMService accounts, keys, workload identity, IAM bindingsPlanned
- Oracle CloudUsers, dynamic groups, API keys, policiesPlanned