AWS IAM: Mastering Entities and Access Control at Scale

This study guide covers the critical aspects of Identity and Access Management (IAM) for the AWS Certified DevOps Engineer Professional exam. We focus on choosing the right entities for human and machine access, policy evaluation logic, and implementing security at scale using federation and advanced policy types.

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between IAM Users, Groups, and Roles for various use cases.
• Determine when to use Identity-based policies versus Resource-based policies.
• Explain the role of Identity Providers (IdP) and AWS IAM Identity Center in federation.
• Apply Session Policies to restrict temporary security credentials.
• Implement Least Privilege using permissions boundaries and Service Control Policies (SCPs).

Key Terms & Glossary

• Principal: An entity (user, role, or application) that can make a request for an action or resource in AWS.
• ARN (Amazon Resource Name): The standard syntax used to uniquely identify AWS resources (e.g., arn:aws:iam::123456789012:user/jdoe).
• STS (Security Token Service): A web service used to request temporary, limited-privilege credentials for users.
• Trust Policy: A resource-based policy attached to an IAM role that defines which principals are allowed to assume the role.
• Trust Anchor: In IAM Roles Anywhere, the certificate authority (CA) used to establish trust between your non-AWS environment and AWS.

The "Big Idea"

In a DevOps environment, identity is the new perimeter. Instead of relying on static IP addresses or firewalls, security is governed by "Who are you?" and "What are you allowed to do?". The goal is to move away from long-term credentials (IAM User Access Keys) toward temporary, short-lived credentials (IAM Roles) for both humans and machines to minimize the blast radius of a potential credential leak.

Formula / Concept Box

IAM Policy Evaluation Logic

By default, all requests are implicitly denied. The evaluation follows this hierarchy:

Hierarchical Outline

• Human Access Management
  • IAM Identity Center: Recommended for multi-account access; integrates with AD/Okta.
  • IAM Groups: Used for "Job Function" assignment; cannot be nested.
  • Federation: Using SAML 2.0 or OIDC to avoid creating IAM users for every employee.
• Machine Access Management
  • IAM Roles for EC2: Uses an Instance Profile to pass temporary credentials to applications.
  • Lambda Execution Roles: Grants the Lambda function permission to access other AWS services.
  • IAM Roles Anywhere: For workloads running on-premises that need to access AWS APIs.
• Advanced Policy Types
  • Session Policies: Passed during the AssumeRole API call to further narrow permissions.
  • Resource-based Policies: Attached to S3 buckets, KMS keys, or SQS queues to grant cross-account access.

Visual Anchors

IAM Role Assumption Flow

This diagram illustrates how a principal (Human or Machine) obtains temporary credentials.

Policy Intersection

Using TikZ to visualize how Permissions Boundaries and Session Policies restrict the final permissions.

Definition-Example Pairs

• Service-Linked Role: A role predefined by an AWS service that includes all permissions the service requires to call other AWS services on your behalf.
  • Example: AWSServiceRoleForAutoScaling allows the Auto Scaling service to delete/create EC2 instances.
• ABAC (Attribute-Based Access Control): Granting permissions based on tags rather than specific resource names.
  • Example: Allowing a developer to stop any EC2 instance where the tag Project matches their own Project tag.
• Session Policy: An inline policy passed via CLI or SDK when assuming a role that limits the role's existing permissions for that specific session.
  • Example: A "Break Glass" admin role is assumed, but the session policy restricts the session to only us-east-1 for emergency maintenance.

Worked Examples

Scenario: Cross-Account S3 Access

Goal: A developer in Account A needs to upload logs to an S3 bucket in Account B.

1. Account B (Resource Owner): Create an S3 Bucket Policy that allows s3:PutObject for the Principal arn:aws:iam::AccountA:role/LogUploaderRole.
2. Account A (Identity Owner): Create a role named LogUploaderRole with a policy allowing s3:PutObject on arn:aws:s3:::account-b-logs/*.
3. The Result: The IAM user/service in Account A assumes LogUploaderRole and can now upload to Account B because both the identity policy and the resource policy allow it.

Checkpoint Questions

1. Can an IAM Group be a Principal in a resource-based policy? (Answer: No, only Users or Roles).
2. What is the main difference between a Service Role and a Service-Linked Role? (Answer: Service Roles are created/managed by you; Service-Linked Roles are predefined and managed by AWS).
3. If an SCP denies s3:* but an Identity-based policy allows s3:GetObject, what is the result? (Answer: Deny; SCPs act as a guardrail).

Muddy Points & Cross-Refs

• Roles vs. Instance Profiles: A common confusion. The Role contains the permissions; the Instance Profile is the "container" that allows the EC2 instance to actually use that role.
• Implicit vs. Explicit Deny: Remember that if no policy mentions a permission, it is an implicit deny. If any policy mentions Deny, it is an explicit deny and overrides everything.
• Deep Dive: Check the AWS IAM Policy Simulator to test complex logic between SCPs and Boundaries.

Comparison Tables

Identity-Based vs. Resource-Based Policies