Day 3 - IAM Policy Deep Dive: Identity vs Resource Policies, Condition Keys, Least-Privilege Design

🔍 Going deeper: An IAM role's trust policy is also a resource-based policy. It is a Principal-containing policy that defines, on the role-as-a-resource, "who may assume this role (sts:AssumeRole)." That is why cross-account AssumeRole requires both sides: ① the target account role's trust policy (with the calling account listed as Principal) and ② an sts:AssumeRole Allow in the caller's identity policy — both are needed (covered in depth on Day 4).

Condition Keys: The Core of Fine-Grained Control

A Condition is a clause that places "additional constraints" on a policy. Here are the keys security engineers use most, organized by type.

Example 1: Forcibly Block Unencrypted S3 Uploads

This bucket policy denies every upload that arrives without the KMS encryption header. It is the classic example of data protection (Domain 5) and governance enforcement.

Example 2: No Sensitive Operations Without MFA

⚠️ Pitfall: The difference between Bool and BoolIfExists is a perennial exam favorite. Some requests (service-to-service calls, STS sessions) do not carry the aws:MultiFactorAuthPresent key at all. If you test for "false" with Bool, you end up blocking legitimate requests that lack the key. BoolIfExists means "if the key exists, check whether it is false; if it does not exist, pass," so it behaves as intended. Also, aws:SourceIp does not apply to traffic that goes through a VPC endpoint — in that case use aws:VpcSourceIp or aws:SourceVpc instead.

🔍 Going deeper: aws:SourceArn and aws:SourceAccount are central to preventing Confused Deputy attacks. For example, when S3 sends events to SNS, if the SNS topic policy does not use aws:SourceArn to state "allow only calls originating from this bucket," someone else's bucket could be abused to trigger your topic. When you trust a service principal (Service principal), you almost always add aws:SourceArn/aws:SourceAccount conditions alongside it (this reappears in an STS context on Day 4).

Permissions Boundary: Least Privilege for Delegation

A Permissions Boundary is a policy that defines "the upper bound on the maximum permissions this principal can have." The identity policy grants permissions; the boundary trims that ceiling. Effective permissions = identity policy ∩ Permissions Boundary (intersection).

Its most powerful use is safely constraining permission delegation — when you want to give a developer "permission to create IAM roles" while preventing the roles they create from becoming admin.

With this, the developer can create roles, but only if DevBoundary is attached as the boundary. The effective permissions of that role can never exceed the boundary — structurally blocking privilege escalation.

💡 Related theory: The evaluation relationship among the four policy types in one picture — SCP (organizational ceiling) ∩ Permissions Boundary (principal ceiling) ∩ Identity policy (grant) → and an explicit Deny wins everywhere. SCPs and boundaries are filters that "trim" permissions, not "grant" them. Session policies (passed at AssumeRole time) work as the same kind of intersection filter.

ABAC: Scalable Least Privilege with Tags

With RBAC (role-based), policies explode as roles multiply. ABAC (Attribute-Based Access Control) expresses permissions with tags, keeping the number of policies constant.

This single policy expresses "allow only when the principal's Project tag matches the resource's Project tag." Even with 100 projects, there is still one policy. When a new team is created, you just assign tags — no policy changes.

🎯 Scenario: "Dozens of teams each operate their own EC2 fleets, and adding IAM policies every time a team is created has hit its limit." The answer is not mass-producing per-team roles and policies but switching to ABAC. Assign a team tag to principals and a team tag to resources, and unify everything under the single condition aws:PrincipalTag/team == aws:ResourceTag/team. Map IAM Identity Center session tags, or SAML/OIDC attributes, to PrincipalTag and the same policy applies to federated users as-is.

Tools That "Discover" Least Privilege

Least privilege is not written from intuition — it is derived from actual usage data.

IAM Access Analyzer's policy generation feature builds a policy from only the actual calls recorded in CloudTrail. Access Advisor (service-last-accessed) shows "permissions not used even once in the last N months," providing evidence for trimming excessive permissions.

📚 Case study: Many organizations start with policies close to *:* and only narrow to least privilege after an incident. Best practice is the reverse — an incremental approach of "add permissions when a needed one is denied." Use a policy generated by Access Analyzer as the starting point, monitor CloudTrail for AccessDenied, and add only what is genuinely needed. "Grant narrowly and widen" does not create security debt the way "grant broadly and narrow" does.

Policy Conflicts and Precedence: A Synthesis

A checklist for quickly adjudicating the outcome when multiple policies intersect.

1. Is there an explicit Deny anywhere? → If so, done — Deny.
2. Does the SCP allow the Action? → If not, Deny.
3. Does the Permissions Boundary allow it? → If not, Deny.
4. (If cross-account) Do both accounts allow it? → If either side is missing, Deny.
5. Is there an explicit Allow? → If not, implicit Deny.
6. All passed → Allow.

💡 Related theory: In this order, steps 2–4 (SCP, boundary, both sides of cross-account) are all "ceiling-trimming filters," and only step 5 (Identity/Resource Allow) is the stage that "grants" permission. Keep this distinction sharp, and the answer to "I have the permission — why is it denied?" almost always turns out to be a block somewhere in the filters (2–4), which you can pinpoint quickly.

Wrapping Up — Precision Is Security

Today's three takeaways. First, identity policies address "what the principal can do"; resource policies address "who can access this resource" — and cross-account access and KMS key policies belong to the resource-policy domain. Second, use Condition keys for fine-grained control based on IP, MFA, encryption, and tags, while avoiding traps like BoolIfExists and aws:SourceArn. Third, Permissions Boundaries and ABAC are the tools for designing least privilege "scalably," and least privilege is derived not from intuition but from Access Analyzer and Access Advisor data.

Tomorrow we move on to STS and temporary credentials. We will dig into exactly how AssumeRole works, what federation and role chaining are, and how to block the Confused Deputy we briefly met today using ExternalId and aws:SourceArn. The trust policies and Condition keys you learned today are the raw material for all of it.