Onam
CIEM

Who can actually do what in my cloud — and how could they escalate?

See what every identity can really do — and the paths it has to admin.

CIEM resolves what human users, roles, service accounts and workload identities can actually do — after group membership, conditions, explicit denies and SCP denies — then finds the escalation paths, the shadow admins, the risky trusts and, on AWS, the permissions nobody uses.

See it in my cloud Read the docs
7
clouds analysed
1,342
CIEM rules
12 hops
assume-role chains traced
4 states
per access review
Illustration: people, workloads and roles connect through an identity graph to cloud resources; one amber path steps through a second role to admin rights, and unused permissions are trimmed.
Illustration. Escalation paths are found across clouds; unused-permission analysis and access reviews run for AWS today.
Why it mattersHow it worksWhat you getFAQ
Why this matters

Nobody can answer 'what can this role actually do?' by reading its policy.

The answer depends on the groups it inherits from, the explicit denies elsewhere, the conditions on each statement and the SCP above the account. And the risk is rarely the role that looks like an admin. It is the CI role with iam:PassRole on a wildcard, the forgotten role that trusts an external account without an ExternalId, or the Kubernetes service account that can create pods/exec. CIEM is the work of resolving that per identity, then ranking what to fix first.

The identity you don't see as admin

Shadow admins never hold an admin policy. They hold the permission that lets them grant themselves one — AttachRolePolicy on a wildcard, CreatePolicyVersion with SetDefaultPolicyVersion, or PassRole to a role that already is admin.

Escalation paths, found per identity
Watch

CIEM in two minutes

Voices are AI-generated. More short Q&A videos: Onam Security: cloud security

How does it actually work?

The mechanism, not the marketing

  1. 1

    Identities and policies come from the cloud inventory Onam's posture scan already builds — IAM users, roles, groups, policies and trust policies on AWS; role definitions and assignments, service principals and managed identities on Azure; IAM bindings, service accounts and workload identity pools on GCP; RBAC bindings and service accounts on Kubernetes; and the identity services of OCI, Alibaba Cloud and IBM Cloud.

  2. 2

    Effective access is resolved per identity. On AWS, group policies are copied onto each member, every condition is classified by whether an attacker could satisfy it, explicit denies are netted out and SCP deny statements are checked. Azure role assignments (with their scope), GCP bindings and Kubernetes RoleBindings resolve into the same effective-access table.

  3. 3

    Each grant gets an access level — admin, IAM control, write, read, list or tagging — and is flagged when it is admin-equivalent, cross-account or blocked by an SCP.

  4. 4

    Identity relationships — has-policy, member-of, assumes and can-access on AWS, plus the link from a VM, instance or pod to the identity it runs as — are written into the platform's security graph, which Attack Path and blast-radius analysis read.

  5. 5

    Detectors look for privilege escalation: PassRole to an admin role, multi-hop assume-role chains that reach admin, permission-boundary removal and shadow admins on AWS, plus escalation vectors for Azure, GCP, OCI, IBM Cloud and Kubernetes.

  6. 6

    On AWS, CloudTrail activity collected by threat detection is joined to the granted actions: roles with no recent activity are flagged as stale, and each identity gets a permission gap — the share of granted actions it never called — with the high-risk unused ones listed.

  7. 7

    AWS identities get a 0–100 risk score from escalation paths, recent use of escalation operations, blast radius and permission gap. Identities in the high tier open an access review with the evidence attached.

What do you actually get?

Specific outputs, measurable outcomes

Effective permissionsShadow adminsEscalation pathsCross-account trustNon-human identitiesUnused permissions (AWS)Identity risk scoreAccess reviews
Effective permissions per identity
after group inheritance, conditions, explicit denies and SCP denies
Shadow admin detection
AWS identities that can attach, rewrite or create their way to an admin policy
Privilege escalation paths
PassRole, multi-hop assume-role chains, boundary removal, and vectors for Azure, GCP, OCI, IBM Cloud and Kubernetes
Cross-account and federated trust
external accounts, wildcard principals, missing ExternalId, OIDC and SAML federation
Non-human identities
roles classified by who can assume them: AWS service, execution, CI/CD over OIDC, EKS service account, cross-account
Unused permissions on AWS
granted actions never seen in CloudTrail, with the high-risk ones called out
Identity risk score
0–100 per AWS identity, with the breakdown behind it
Blast radius
how many resources with open high or critical findings an identity can reach
Stale roles
AWS roles with no recent API activity
Access reviews
pending, needs remediation, reviewed or deferred, with an audit trail and decisions that expire
Kubernetes RBAC
service accounts bound to cluster-admin, able to read secrets, exec into pods or rewrite roles
Database identity activity
superuser and role-grant changes and login anomalies, from credentialed database connections
The whole picture

From identity sources to a decision

CIEM reads the identities Onam's posture scan already inventories, resolves what each one can do, records how they connect, and turns that into findings a person can act on.

Onam CIEM: identity sources from seven clouds feed an effective-permission resolver, which builds an identity graph and produces escalation, trust, unused-permission, risk-score and access-review outputs
Capability by capability

What CIEM works out, and where

Each card says which clouds it runs on today. AWS has the deepest coverage; we would rather say that than let a checkmark imply otherwise.

Effective permissions

Group policies are copied onto each member, conditions are classified by whether an attacker could meet them, explicit denies override allows, and SCP deny statements are checked. Each grant is labelled admin, IAM control, write, read, list or tagging.

AWS in full · Azure, GCP and Kubernetes assignments and bindings

Identity graph

Has-policy, member-of, assumes and can-access edges, plus the link from a VM, instance or pod to the identity it runs as. Attack Path and blast-radius analysis read the same graph.

AWS identity edges · runs-as links on Azure, GCP and Kubernetes

Escalation paths and shadow admins

PassRole to an admin role, multi-hop assume-role chains, permission-boundary removal, and identities that can attach or rewrite their way to an admin policy — plus each cloud's own escalation vectors.

AWS, Azure, GCP, OCI, IBM Cloud, Kubernetes · shadow admins on AWS

Cross-account and federated trust

Role trust policies checked for foreign accounts, wildcard principals, a missing ExternalId and OIDC or SAML federation, including from GitHub, GitLab, GCP and Azure.

AWS in depth · cross-tenant, trusted-profile and RAM trust checks elsewhere

Non-human identities

Roles classified by who can assume them — AWS services, execution roles, CI/CD over OIDC, EKS service accounts, cross-account principals. Managed identities, service accounts and Kubernetes service accounts are resolved like users.

AWS, Azure, GCP, Kubernetes

Unused permissions

CloudTrail activity collected by threat detection is compared with granted actions. You get a permission gap per identity, the high-risk unused actions such as iam:PassRole or kms:ScheduleKeyDeletion, and a list of roles with no recent activity.

AWS today

Risk score and access reviews

A 0–100 score built from escalation paths, recent escalation activity seen by CDR, blast radius and permission gap. High-tier identities open a review: pending, needs remediation, reviewed or deferred, with an audit trail.

AWS identities today

Read the CIEM docs

How effective permissions are computed, every finding type, the right-sizing workflow and per-cloud notes.

Open the docs
Per-cloud coverage

What runs on which cloud today

CapabilityAWSAzureGCPK8sOCIAlibabaIBM
Effective-access table
Escalation detection
Multi-hop assume-role chains
Shadow admin detection
Trust and federation checks
Unused permissions and stale roles
Risk score and access reviews
Identity hygiene (IAM Security)

Identity hygiene — MFA, key age, password policy, root usage — is covered on all seven clouds through IAM Security, which shares this engine and inventory.

One-page overview

CIEM on one page

Inputs, how it works, what you get and the limits — the same sheet our team uses in briefings.

Download (PNG)
CIEM one-page overview: inputs, how it works, what you get, outcomes and limits. Open full size
FAQ

Questions we get a lot

On AWS, Onam starts from every identity-based policy statement, copies group policies onto each member user, and classifies every condition by whether an attacker could satisfy it. Explicit denies are netted out unless their own condition is one an attacker cannot meet, and SCP deny statements are checked where Onam can read your AWS Organization. The result is one row per identity, resource scope and access level, marked admin, cross-account or SCP-blocked where that applies. Azure role assignments, GCP bindings and Kubernetes RoleBindings resolve into the same table.
Ready to see it live

Ready to see CIEM in your cloud?

Connect a read-only role in three minutes. Your first findings surface in under five.

Book a live demo →See pricing
Related capabilities
CIEM documentationWhat is CIEM?IAM Security — identity hygieneAttack PathCDR — cloud detection & responseCIEM vs IAM security — the practical difference