Resource-based policy

Definition

A resource-based policy is attached to the resource - a bucket policy, a KMS key policy, an IAM role trust policy, a queue policy - and names the principals that may act on it. Inside one account it is a granting class and combines with identity-based policies by union. Across accounts it is the trusting side of a two-evaluation conjunction: the request is allowed only if both accounts allow it.

The problem

Its meaning changes with the principal form it names and with the account boundary it sits on. The same document is a grant in one row of the evaluation matrix and a ceiling in the next, and inside one account it cannot reduce what an identity-based policy grants at all: the tightening design most teams intend is a union, not an intersection.

Why it matters

It is the only class a resource owner controls without editing anyone else’s identity policies, which is why it is the correct plane for cross-account sharing - and why a restrictive resource policy written to constrain a colleague’s role inside one account constrains nothing at all.

Practical example

A bucket policy naming arn:aws:iam::111122223333:role/examplerole is capped by that role’s permissions boundary. The same policy naming arn:aws:sts::111122223333:assumed-role/examplerole/sessionname is not. Both read, in review, as "the bucket allows the role".

How RELIASTRA approaches it

As with identity-based policies: RELIASTRA records the outcome a dependency produced and the moment it produced it, and keeps that record separate from any claim about the dependency’s own policy set, which RELIASTRA does not observe.