Glossary
Identity-based policy
A policy attached to an IAM principal that states what that principal may do.
Definition
An identity-based policy is attached to an IAM user, group or role and grants or denies actions to the principal it is attached to. Inside one account it is one of the two granting classes: with resource-based policies it combines by union, so an Allow in either is sufficient, and an explicit Deny in either overrides the Allow.
The problem
Because the union is easy to forget, teams search the class they author most often. A role found reading a bucket it should not is usually blamed on its identity policy while the grant sits in the bucket policy - equally sufficient, and invisible from the identity side.
Why it matters
The class a grant lives in decides who owns it, who reviews it and what caps it. An identity-based grant travels with the principal and is capped by that principal’s permissions boundary and session policies. A resource-based grant does not, and can bypass ceilings the author of the identity policy assumed applied.
Practical example
The same s3:GetObject Allow written in a role policy is capped by the boundary attached to that role. Written instead in the bucket policy naming the role session ARN, it is not. The two grants are one ARN format apart and behave differently under the same boundary.
How RELIASTRA approaches it
RELIASTRA treats the two planes as separate objects of evidence. When a dependency refuses a call, the record shows the outcome and its timestamp; which policy on the dependency side produced it is a claim RELIASTRA does not make without evidence that reaches it.
Add one dependency you already own.
RELIASTRA probes the external services your software relies on, confirms a fault deterministically, and keeps a record you can verify later. One plan, $9/month, and a 14-day trial that needs no card.