5.2.3. IAM Policies and Least Privilege

First Principle: Least privilege means granting the minimum permissions necessary for a task — no more, no less. In practice, this means starting with zero permissions and adding only what's needed, rather than starting with broad access and trying to restrict it.

Policy Evaluation Logic:

1. Default deny — all requests start as denied
2. Evaluate SCPs — if SCP doesn't allow, request is denied (applies in Organizations)
3. Evaluate resource policies — if resource policy grants access and no explicit deny exists, request may be allowed
4. Evaluate identity policies — identity must have an Allow statement for the action
5. Evaluate permissions boundaries — if boundary doesn't include the action, denied
6. Evaluate session policies — if session policy restricts the action, denied
7. Explicit deny wins — an explicit Deny in ANY policy type overrides all Allow statements

Permissions Boundaries:

• Set the maximum permissions an identity can have — even if an identity policy grants broader access
• Use case: allow developers to create IAM roles but limit what those roles can do
• The effective permission is the intersection of the identity policy and the boundary

Session Policies:

• Passed when calling AssumeRole to further restrict the role's permissions for that specific session
• Use case: temporary, scoped access for a specific task
• The effective permission is the intersection of the role's identity policy and the session policy

Least-Privilege Design Process:

1. Define the specific task (e.g., "Lambda function reads from DynamoDB table X")
2. Identify the minimum actions (dynamodb:GetItem, dynamodb:Query)
3. Scope the resource (arn:aws:dynamodb:us-east-1:123456789012:table/X)
4. Add conditions where possible (aws:SourceVpc, aws:RequestedRegion)
5. Use IAM Access Analyzer to identify and remove unused permissions over time

⚠️ Exam Trap: An explicit Deny in ANY policy type overrides all Allow statements. If an SCP denies an action, no identity policy or resource policy can override it. This is the single most important rule for policy evaluation questions.

Scenario: A developer needs to deploy Lambda functions. You create a permissions boundary that allows only lambda:*, iam:PassRole for specific execution roles, and logs:*. Even if the developer modifies their own identity policy to add s3:*, the boundary prevents S3 access.

Reflection Question: Why are permissions boundaries critical for delegated administration, and how do they prevent the "self-escalation" problem?