The cloud identity model

The principal: who is asking

Every authorization decision starts with a principal — the entity making the request. In a cloud IAM model the principal is almost never a human typing a password. It is an identity that has already been authenticated and now carries a set of short-lived credentials: an IAM role assumed by an EC2 instance, a Kubernetes service account exchanged for a cloud token via workload identity, a CI job that federated in with an OIDC token, a Lambda’s execution role. The login already happened; by the time a policy is evaluated, the platform knows which principal is asking. IAM is the authorization layer, not the authentication layer — it answers “is this already-known principal allowed to do this action on this resource,” and that distinction is where most confusion starts.

This matters for a senior reason: principals are usually machines, and they are long-lived in intent but short-lived in credential. A role doesn’t have a password; a principal assumes it and receives credentials that expire in an hour. So the interesting attack surface is not “guess the password” — it’s “who is allowed to become this principal,” which is governed by a separate policy we’ll get to.

Two policy questions: identity vs resource

A cloud platform asks the same request from two directions, and both must agree.

• An identity-based policy is attached to the principal (a role, a user, a group). It says what this principal can do: “the report-writer role may s3:PutObject on reports-bucket.” Read it as a sentence starting with the actor.
• A resource-based policy is attached to the resource itself (an S3 bucket, an SQS queue, a KMS key). It says who may act on this resource: “this bucket allows arn:aws:iam::111:role/report-writer to read.” Read it as a sentence starting with the object.

The same access can be expressed from either side, and the combination is what makes cross-account access work without anyone editing the other account’s roles. If account A’s bucket has a resource policy naming account B’s role, and B’s role has an identity policy allowing the action, the request succeeds — neither side could grant it alone across an account boundary. This is also the single most common source of “why can it read that?”: the grant lives on the resource, not the identity, so reading only the role’s policy will never explain it.

The trust policy: who may become this principal

A role has a door, and the trust policy is the lock on it. It is a resource-based policy that lives on the role and answers a question the identity policy never touches: who is allowed to assume this role at all? The identity policy says what the role can do once you’re inside; the trust policy says whether you may walk in.

This split is the whole engine of cloud federation. A GitHub Actions job presenting an OIDC token can become a deploy role only because that role’s trust policy says “principals federated from this OIDC provider, with this sub claim, may assume me.” A human in your SSO directory becomes an admin role because the trust policy trusts the identity provider. Get the trust policy wrong — trust *, or trust an OIDC sub with a sloppy wildcard like repo:org/* — and you have handed the role to the entire internet, no matter how tight its identity policy is. The trust policy is the part juniors forget exists and seniors review first, because it is the actual authentication boundary for a machine principal.

How the decision is actually evaluated

Here is the rule that dissolves the mysteries. Cloud authorization is deny by default, and evaluation is not “find a matching allow” — it is a fixed precedence:

1. Start at implicit deny. No statement matches → the request is denied. Nothing is permitted unless something grants it.
2. An explicit Deny always wins. If any applicable policy — identity, resource, boundary, or org guardrail — contains a Deny that matches, the request is denied, full stop. No allow can override it.
3. An explicit Allow lifts the implicit deny — but only within the ceiling. A permission boundary or org-level guardrail (an SCP) can cap what is reachable even when an identity policy says Allow; the effective permission is the intersection of what’s granted and what the ceiling permits.

So the real evaluation is: deny unless (some policy allows) AND (no policy denies) AND (the grant is inside every applicable ceiling). That ordering is why an over-broad Allow * is far less dangerous than people fear when a boundary caps it — and why a single stray Deny can break a deploy that “obviously has permission.”

Reading a real grant: cross-account in one merge

Walk the opening mystery through the model. Your role in account B can s3:ListBucket on a bucket in account A. Trace it:

• Trust policy on B’s role lets your EC2 instance / CI job assume it. Authentication of the machine principal: done.
• Identity policy on B’s role allows s3:ListBucket on arn:...:bucket-in-A. B’s side of the grant: present.
• Resource policy on A’s bucket allows arn:aws:iam::B:role/yours to s3:ListBucket. A’s side of the grant: present.
• No Deny anywhere, and the action sits inside B’s permission boundary and A’s org guardrails.

Both sides agreed, no deny intervened, the ceiling allowed it → permitted. The reason reading the role alone failed is that half the grant lived on the resource in another account. The senior habit is to ask, for any surprising access: “show me every policy in the merge — both identities, both resources, the boundary, the org guardrail — not just the one I expected.”