Scaling Identity and Access Management in AWS

This study guide focuses on implementing identity and access management (IAM) across large-scale, multi-account environments, a critical domain for the AWS Certified DevOps Engineer Professional exam.

Learning Objectives

By the end of this guide, you should be able to:

• Design and implement least privilege access policies for human and machine identities.
• Configure IAM Identity Center for centralized federation with external identity providers (IdPs).
• Implement Service Control Policies (SCPs) and Permissions Boundaries to enforce organizational guardrails.
• Distinguish between and implement Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) patterns.
• Automate credential rotation and secure multi-account access strategies.

Key Terms & Glossary

• SCP (Service Control Policy): An organization policy used to manage permissions in your organization, acting as a filter for what services/actions are available to accounts.
• Permissions Boundary: A managed policy that sets the maximum permissions that an identity-based policy can grant to an IAM entity.
• Identity Federation: A system that links a person's electronic identity and attributes, stored across multiple distinct identity management systems.
• ABAC (Attribute-Based Access Control): An authorization strategy that defines permissions based on attributes (tags in AWS).
• IAM Identity Center: The successor to AWS Single Sign-On, providing a central place to manage SSO access to all AWS accounts and cloud applications.

The "Big Idea"

As organizations scale from a single AWS account to hundreds, managing individual IAM users becomes an administrative nightmare and a security risk. The "Big Idea" is to move from decentralized, manual management to centralized, automated governance. This is achieved by federating identities from a single source of truth (like Active Directory) and using hierarchical guardrails (SCPs and Boundaries) to delegate power to developers without sacrificing security.

Formula / Concept Box

IAM Policy Evaluation Logic

When a request is made, AWS evaluates policies in a specific order. A single Explicit Deny anywhere overrides everything.

[!IMPORTANT] If no policy allows the action, it is an Implicit Deny by default.

Hierarchical Outline

• I. Centralized Identity Management
  • AWS IAM Identity Center (SSO): Primary tool for multi-account access.
  • Identity Federation: Connecting AD, Okta, or PingFederate via SAML 2.0.
• II. Policy Guardrails at Scale
  • Service Control Policies (SCPs): Root-level restrictions; does not grant permissions, only filters them.
  • Permissions Boundaries: Used to delegate IAM creation to users without allowing privilege escalation.
• III. Access Control Patterns
  • RBAC: Access based on job function (Groups/Roles).
  • ABAC: Access based on resource and principal tags (Scaling with tags).
• IV. Machine Identity Security
  • AWS Secrets Manager: Automated rotation for API keys and database credentials.
  • IAM Roles for EC2/ECS: Eliminating long-term access keys.

Visual Anchors

Identity Federation Flow

Multi-Account Guardrail Layers

Definition-Example Pairs

• Least Privilege: The practice of granting only the absolute minimum permissions required to perform a task.
  • Example: Instead of s3:*, a Lambda function is granted s3:GetObject only on the specific bucket my-app-logs-123.
• Attribute-Based Access Control (ABAC): Granting access based on metadata matching.
  • Example: An IAM policy allows developers to start EC2 instances only if the user's tag ProjectID matches the instance's tag ProjectID.
• Just-In-Time (JIT) Provisioning: Creating user accounts or granting access dynamically at the moment of login.
  • Example: A user logs in via SAML; IAM Identity Center automatically assigns them to the "DevOps-Audit" role based on their AD group membership for that session only.

Worked Examples

Scenario: Preventing Privilege Escalation

Problem: You want to allow a Junior Admin to create IAM roles for Lambda functions, but you are afraid they will create a role with AdministratorAccess and use it themselves.

Solution: Implementation of a Permissions Boundary.

1. Create a "Boundary Policy" that allows only S3 and CloudWatch access.
2. Attach a policy to the Junior Admin that allows iam:CreateRole ONLY IF the iam:PermissionsBoundary parameter is set to the S3/CloudWatch policy.
3. Result: Any role the Junior Admin creates is limited by the boundary, regardless of what they put in the role's inline policy.

Scenario: Enforcing MFA via Policy

Explanation: This policy snippet (often used in SCPs or Identity policies) ensures that if MFA is not present in the session, every action is denied.

Checkpoint Questions

1. Which AWS service allows you to centrally manage SSO access to multiple AWS accounts?
2. Does an SCP grant permissions to a user within an account? Why or why not?
3. How does ABAC simplify permission management as the number of resources grows?
4. What is the main difference between a Permissions Boundary and an SCP?

▶Click to see answers

1. AWS IAM Identity Center.
2. No. SCPs only specify the maximum permissions available (the filter). An IAM policy within the account must still explicitly grant the permission.
3. ABAC uses tags; you don't need to update IAM policies when new resources are added, as long as the new resources are tagged correctly.
4. SCPs apply to the entire account/OU (Organizational level), while Permissions Boundaries are applied to specific IAM users or roles (Identity level).

Muddy Points & Cross-Refs

• SCP vs. Boundary: This is a common point of confusion. Remember: SCP = Outer Wall (Account-wide), Boundary = Inner Cage (User-specific).
• Trust Policy vs. Identity Policy: A Trust Policy defines who can assume a role (the Principal). An Identity Policy defines what that role can do once assumed.
• Session Policies: Often overlooked, these are used in AssumeRole API calls to further restrict a session. They cannot grant more than the Role's identity policy allows.

Comparison Tables

RBAC vs. ABAC