Cloud IAM: trust, delegation and effective permissions

Prove which principal can act on which resource, including cross-account trust, delegated roles and workload federation.

Used in these playbooks#

Setup and security invariant#

Use two owned accounts or explicitly supplied test identities: an administrator for fixtures, principal A with restricted rights, and principal B representing the allowed integration. Record account IDs, role ARNs, session type, region, policy versions and a synthetic object. The invariant is precise: A cannot obtain B's authority or make a service exercise it on A's behalf. Reuse the authorization matrix for rows and evidence naming.

Before cloud testing, check the current provider policy for the exact service and activity. AWS customer testing permission does not extend to attacking the provider itself. AWS testing policy

Procedure#

1. Confirm identity, then map enforcement. Write one row for caller → trust policy → assumed role → service API → resource. Collect owner-supplied identity and resource policies, session restrictions, boundaries and organization restrictions. An isolated wildcard allow does not establish effective access. Preserve missing policy visibility as an explicit uncertainty. AWS policy evaluation

2. Create paired controls. B performs one approved metadata lookup against the canary; A attempts the identical operation and should be denied. Use fresh sessions and the same resource identifier. If both fail, repair the fixture or connectivity before testing a vulnerability hypothesis.

3. Change one trust input. With two owned integration identities, compare the documented allowed principal with the disallowed one. For a third-party integration, inspect who assigns the external ID and whether the service ties it to the correct customer. A missing external ID alone is not universally a vulnerability: demonstrate the applicable confused-deputy path. Third-party role access

4. Test delegation separately. Review whether A can select a more powerful service role while creating or updating a workload. In an isolated account, use a single approved disposable job that only checks canary metadata. Compare its normal role with the proposed excessive role. Record both workload-creation permission and role trust; PassRole alone is insufficient. The relevant audit event is the service create/update operation because PassRole is a permission, not an independent API event. PassRole documentation

5. Check federation claims. In an owned identity-provider fixture, change only one legitimate token claim: subject, audience, repository, branch or environment, as applicable. Do not forge another organization's identity. Record which rule rejects the negative case. Token correctness and cloud role selection are separate checks; reuse identity and sessions. OIDC role trust

Command card#

Replace identifiers with the fixture values. Run individually; the profiles must already use owned credentials. Commands inspect identity, trust and one object's metadata.

aws --profile lab-low sts get-caller-identity \
  --no-cli-pager --cli-connect-timeout 5 --cli-read-timeout 10

aws --profile lab-owner iam get-role --role-name BountyFixture \
  --query 'Role.{Arn:Arn,Trust:AssumeRolePolicyDocument}' \
  --no-cli-pager --cli-connect-timeout 5 --cli-read-timeout 10

aws --profile lab-low s3api head-object \
  --bucket OWNED_BUCKET --key bounty/canary.txt \
  --expected-bucket-owner YOUR_ACCOUNT_ID \
  --no-cli-pager --cli-connect-timeout 5 --cli-read-timeout 10

Repeat the last command with the allowed fixture profile. Expect metadata for the allowed principal and denial for A. A denied metadata request can also mean a missing object: establish existence using the owner control. GetRole CLI, HeadObject semantics, caller identity

Evidence, false positives and cleanup#

Save the principal/resource matrix, exact changed input, redacted policies, request IDs and one audit event. Distinguish policy candidate, successful authority acquisition, and demonstrated canary access. Intended administrator delegation, denied actions and policy simulation alone do not prove escalation. Delete disposable jobs and roles by recorded fixture IDs; revoke fixture sessions where supported and verify canary access is denied again.

• Effective caller and resource owner captured.
• Allowed and denied controls use the same operation.
• Trust, service creation and data permission distinguished.
• Tokens and live credentials excluded from the report.
• Fixture removal and post-cleanup denial recorded.

The worked commands below use AWS. For Azure managed identities, management/data separation, and GCP service-account attachment versus impersonation, continue with Azure and GCP boundaries.

Vulnerability reverse references#

• Overbroad cloud role trust — A principal outside the integration's intended trust set can obtain an owned role's authority.
• Excessive service-role delegation — A restricted principal can cause an allowed service to execute with a more powerful role than the application contract permits.
• Federated cloud role accepts the wrong workload identity — OIDC role trust accepts a legitimate token from a disallowed controlled subject, repository, branch or audience.
• Workload creation grants unintended service-account authority — An allowed workload-creation path lets a tenant select a service account or resource mount exceeding its promised permissions.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity · Proxy normalization, cache isolation, and request boundaries