Cloud IAM: review privilege paths, not permission lists

The permission you can acquire matters too

An identity can appear limited when its own policies are read in isolation, yet still control a workload that runs as a more privileged identity. The security question is not only “what can this principal read?” It is also “which principals can it become, configure or cause to act?” Effective access is a relationship between identities, resources, trust policies and conditions.

Start with an inventory of human identities, CI/CD identities, runtime roles and service accounts. For each, record how credentials are issued, where the identity can authenticate and which other identities or workloads it can influence. Include deployment permissions, policy editing, role assumption, credential minting and changes to code executed by an existing privileged runtime.

An AWS path: deployment control plus role passing

Imagine a deployment identity allowed to create a test Lambda function and pass a runtime role to it. If that role is more privileged than the deployment identity, code running in the function may gain access the deployer could not exercise directly. This is a conditional path, not a claim that iam:PassRole alone grants execution or access. The caller needs relevant service permissions, the role must trust the service, and the applicable authorization policies must permit the operation.

Illustrative access path

CI deployment identity
  ├─ can create/configure the test workload
  ├─ can pass a specified IAM role
  └─ runtime role trusts the workload service
       ↓
Code executes as that runtime role
       ↓
Runtime role's permitted resources become reachable

Role passing is not the only edge. Permission to update code in an already privileged function may matter even when the role cannot be changed. A reviewer who searches only for broad PassRole grants can miss that path. Conversely, finding a broad grant does not establish an exploitable path until service permissions, trust relationships, boundaries and applicable denies have been examined.

Constrain the role and the service together

Where role passing is needed, allow only the intended role resources and service destination. The following policy illustrates a narrow PassRole grant. It is one part of a deployment policy—not a complete deployment configuration or a proof that the runtime role itself is safe.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PassOnlyTheExampleRuntimeRole",
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::123456789012:role/service-role/example-runtime",
    "Condition": {
      "StringEquals": {
        "iam:PassedToService": "lambda.amazonaws.com"
      }
    }
  }]
}

Review the runtime role’s own permissions and trust policy, and restrict who can change them. Account for identity policies, resource policies, session policies, permissions boundaries and organizational controls according to AWS policy-evaluation rules. Their interaction depends on the principal and resource involved; a boundary should not be described as a universal deny that behaves identically for every resource-policy grant.

A Google Cloud path: service-account impersonation

Service-account impersonation allows one authenticated identity to obtain short-lived credentials for a service account. The Service Account Token Creator role can enable credential minting; granting it too broadly can make many service accounts reachable. Short token lifetimes reduce credential exposure, but do not make excessive impersonation authority harmless.

Distinguish this from the Service Account User role and its actAs permission, which is used when attaching a service account to supported resources. A path through deployment plus actAs is not the same as directly minting a token. Model both paths, including whether the caller can modify a workload after it has been deployed. Prefer narrowly scoped grants on the required service account, and use federation and short-lived credentials where appropriate instead of distributing long-lived keys.

Validate without collecting sensitive data

Agree on a benign target and success condition before exercising a path. A dedicated test object or an identity-inspection operation can often demonstrate the effective principal without reading application secrets or customer records. Capture the starting identity, relevant permission edges, evaluated conditions and resulting identity. If a path is blocked by a real control, record that control rather than reporting an unverified chain as an achieved escalation.

• Check who can create roles, attach or replace policies, edit trust policies, grant impersonation, create keys and alter privileged workload code.
• Separate deploy-time permissions from runtime permissions and review both. A constrained CI identity is not enough if its runtime role is unnecessarily broad.
• Review temporary access and inherited/project-wide grants. Identify the scope and duration of each edge rather than treating every role binding as equivalent.
• Verify the relevant audit trail. In AWS, PassRole is a permission rather than a standalone API call, so inspect the service operation that used the role instead of expecting a separate PassRole event.
• After narrowing access, repeat the benign path test and a legitimate deployment. Security remediation should block the unintended path without silently breaking required operations.