AWS & SRE Field Manual (Part 1): Zero-Trust Identity & Access Management (IAM)

📌 TL;DR & Problem Statement

• Definition: The centralized security control plane that manages authentication and authorization across all AWS cloud resources. It serves as the native AWS equivalent of Kubernetes RBAC.
• Problem Solved: Secures access to infrastructure resources using centralized, auditable, fine-grained, and temporary security credentials instead of distributed, static passwords and access keys.
• Category: Security, Identity, & Compliance
• Core Rule (Implicit Default Deny): All API requests across AWS are strictly denied by default unless explicitly granted by a matching Allow statement.

---

🏛️ Core Architecture & Key Components

1. IAM Users (Human Identities & Static Credentials)

• Represents discrete individuals interacting with AWS.
• Access is provided via console password with mandatory Multi-Factor Authentication (MFA), or programmatic access via static AccessKeyId and SecretAccessKey pairs.
• Root Account: The initial, all-powerful identity created upon account registration. It must be locked behind hardware/virtual MFA immediately, stripped of static access keys, and reserved exclusively for emergency break-glass procedures.

2. IAM Groups (Role-Based Membership)

• Logical collections of users sharing identical permission requirements (e.g., DevOps-Admins, Data-Engineers).
• Attaching permissions directly to individual users is an anti-pattern; policies attach to groups, and users inherit privileges through group membership.

3. IAM Roles & AWS STS (Temporary Credentials & Workload Identity)

• An identity abstraction without permanent passwords or static keys, assumed dynamically via the sts:AssumeRole API.
• Mirrors the mechanics of Kubernetes ServiceAccounts and EKS IRSA / Pod Identities. Workloads (EC2 instances, Lambda functions, ECS/EKS pods) obtain short-lived, self-expiring tokens generated by the AWS Security Token Service (STS).
• Blast Radius Reduction: Even if a compute instance or container is compromised, the leaked STS token expires within minutes to hours, preventing long-term credential exfiltration.

4. IAM Policies (Declarative Permission Documents)

• Structured JSON documents defining who can execute specific actions against target resources under designated conditions:
  • Effect: Explicit Allow or Deny (an Explicit Deny unconditionally overrides any Allow).
  • Action: Targeted API operations (e.g., s3:GetObject, ec2:DescribeInstances).
  • Resource: The target Amazon Resource Name (ARN) governed by the statement (e.g., arn:aws:s3:::production-app-bucket/*).
  • Condition: Contextual prerequisites required to satisfy the policy (source IP ranges, MFA enforcement, secure transport, resource/principal tags).

---

⚙️ Deep Dive Engineering & Authorization Mechanisms

Policy Evaluation Logic (Order of Precedence)

Incoming API Request
        │
        ▼
[ Is there an Explicit Deny? ] ─────── YES ────► [ Access Denied ]
        │
        NO
        ▼
[ Does SCP allow it? ] ─────────────── NO  ────► [ Access Denied ]
        │
       YES
        ▼
[ Does Resource Policy allow it? ] ─── YES ──┐
        │                                    │
        NO                                   │
        ▼                                    │
[ Does Identity Policy allow it? ] ─── YES ──┼──► [ Check Boundaries/Session ] ──► [ Access Granted ]
        │                                    │
        NO                                   │
        ▼                                    │
 [ Access Denied (Implicit Deny) ] ◄─────────┘

1. Is there an Explicit Deny anywhere in the evaluation chain? (If yes, immediate termination and rejection).
2. Does an AWS Organizations Service Control Policy (SCP) permit the request?
3. Does a Resource-based Policy (e.g., S3 Bucket Policy, KMS Key Policy) allow the action?
4. Does an Identity-based Policy (IAM Policy attached to the principal) allow the action?
5. Does the request fall within the ceiling defined by Permissions Boundaries and Session Policies?
6. Outcome: If any evaluation point yields an Explicit Deny, or if no policy grants an explicit Allow, the request is dropped (Implicit Deny).

IAM Permissions Boundaries

• Defines the maximum permission ceiling for an IAM entity.
• Enables delegating policy creation to development teams without risking privilege escalation. Even if a developer creates a new role with AdministratorAccess, the effective permissions will never exceed the attached Permissions Boundary (e.g., S3FullAccessBoundary).

Attribute-Based Access Control (ABAC) & Session Tags

• Grants dynamic access based on matching metadata tags rather than maintaining complex, static JSON policies per user.
• A single generic policy allows access if the principal's department or project tag matches the target resource tag (aws:ResourceTag/Project == aws:PrincipalTag/Project).

Cross-Account Access & ExternalID (Confused Deputy Protection)

• When delegating role access to third-party SaaS vendors (e.g., Datadog, Databricks), requiring an sts:ExternalId condition inside the Role Trust Policy is mandatory.
• Prevents the Confused Deputy attack vector, where an adversary manipulates the third-party platform into assuming another customer's role inside your AWS account.

---

💻 Practical Notes & Configuration Snippets

Attribute-Based Access Control (ABAC) Policy (Tag-Match Enforcement)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    }
  ]
}

Essential AWS CLI Commands for IAM & STS

# Check current caller identity and active ARN
aws sts get-caller-identity

# Assume an IAM Role manually (returns temporary credentials)
aws sts assume-role \
  --role-arn "arn:aws:iam::123456789012:role/DevOpsAdminRole" \
  --role-session-name "CLI-Session" \
  --external-id "UniqueSecretId123"

# List IAM policies attached to a specific group
aws iam list-attached-group-policies --group-name "Engineering-Team"

---

⚠️ Gotchas & Common Pitfalls

• Eventual Consistency in IAM APIs: IAM is a globally distributed control plane. Changes to policies, roles, or group memberships take several seconds to propagate across all AWS edge endpoints worldwide. Automation scripts and CI/CD pipelines must incorporate exponential backoff or brief delay retries immediately following IAM resource provisioning.
• Identity-Based vs. Resource-Based Policy Overlaps: An Identity-based policy is a credential held by the caller; a Resource-based policy (e.g., S3 Bucket Policy, SQS Policy) is an access control list on the target resource. Within the same AWS account, if a resource-based policy grants explicit access, the caller can execute the action even without an attached identity-based IAM policy.
• Wildcard (*) Operator Abuse: Using Action: "" and Resource: "" violates the Principle of Least Privilege and represents the primary security vulnerability identified during compliance audits.

---

💡 Production Best Practices

• Enforce IMDSv2 Globally: Prevent SSRF-driven IAM token leakage from compute nodes by enforcing IMDSv2 (HttpTokens=required, HttpPutResponseHopLimit=1) across all EC2 launch templates and running instances.
• Automate IAM Access Analyzer: Enable IAM Access Analyzer across the organization to automatically flag external, cross-account, and public access to S3 buckets, KMS keys, and IAM roles.
• Root Account Monitoring & Alarms: Deploy an Amazon EventBridge rule tied to SNS alerts to notify security teams immediately via Slack or PagerDuty whenever the Root user logs into the AWS Management Console or triggers an API call.
• Service Control Policies (SCPs) as Hard Guardrails: Implement SCPs at the AWS Organizations root to enforce organizational compliance (e.g., restricting available AWS Regions or denying modification to security audit log buckets). SCP Deny statements cannot be bypassed by any user within a member account, including IAM identities with full AdministratorAccess.