8.1 Advanced IAM — Permission Boundaries, Federation, and Cross-Account
Key Takeaways
- Permission boundaries set the maximum permissions an IAM entity (user/role) can have — even if a policy grants broader access, the boundary caps it.
- AWS IAM Identity Center (formerly SSO) provides centralized single sign-on access to multiple AWS accounts and business applications.
- Cross-account access uses IAM roles: create a role in the target account with a trust policy allowing the source account to assume it.
- Resource-based policies (S3 bucket policies, SQS policies, KMS key policies) can grant cross-account access without assuming a role.
- IAM Access Analyzer identifies resources shared with external accounts, helping you find unintended public or cross-account access.
Advanced IAM — Permission Boundaries, Federation, and Cross-Account
Quick Answer: Permission boundaries cap max permissions for users/roles. IAM Identity Center provides SSO across accounts. Cross-account access uses roles (trust policy in target, assume role from source). Resource-based policies grant cross-account access without role assumption. Access Analyzer finds unintended external sharing.
Permission Boundaries
A permission boundary is a managed policy that sets the maximum permissions that an IAM entity can have.
How It Works
Effective permissions = Identity policy INTERSECT Permission Boundary
| Identity Policy Grants | Permission Boundary Allows | Effective Permissions |
|---|---|---|
| s3:, ec2:, rds:* | s3:, ec2: | s3:, ec2: (rds:* blocked) |
| s3:GetObject | s3:, ec2: | s3:GetObject |
| ec2:TerminateInstances | s3:* only | None (ec2 not in boundary) |
Use Cases
- Allow developers to create IAM roles (for Lambda, EC2) without granting themselves admin privileges
- Delegate permission management to team leads while limiting what they can grant
- Prevent privilege escalation by capping the maximum permissions any created role can have
IAM Identity Center (SSO)
IAM Identity Center (formerly AWS SSO) provides centralized access management for multiple AWS accounts.
| Feature | Detail |
|---|---|
| Single sign-on | One login for all AWS accounts and applications |
| Identity source | Built-in directory, Active Directory, or external IdP (SAML 2.0) |
| Permission sets | Predefined or custom sets of permissions assigned to users/groups |
| Multi-account | Manage access across all accounts in an Organization |
| Business apps | SSO to SaaS applications (Salesforce, Slack, etc.) |
| ABAC | Attribute-based access control using user attributes |
On the Exam: "Enterprise employees need single sign-on to multiple AWS accounts" → IAM Identity Center. "Developers need temporary cross-account access" → IAM roles with trust policies.
Cross-Account Access
Method 1: IAM Roles (Most Common)
- Target account creates a role with a trust policy allowing the source account
- Source account user/role calls
sts:AssumeRoleto assume the target role - STS returns temporary credentials for the target account
- User/application uses temporary credentials to access target account resources
Method 2: Resource-Based Policies
Some resources support policies that directly grant cross-account access:
- S3 bucket policies
- SQS queue policies
- SNS topic policies
- KMS key policies
- Lambda function policies
Advantage: No need to assume a role — the calling principal keeps their identity.
Method 1 vs. Method 2
| Feature | IAM Roles | Resource-Based Policies |
|---|---|---|
| Identity | Assumes a new identity | Keeps original identity |
| CloudTrail | Logged as role in target account | Logged as original principal |
| Supported by | All services | Only some services |
| Use case | General cross-account access | S3, SQS, KMS, Lambda cross-account |
IAM Access Analyzer
| Feature | Detail |
|---|---|
| Purpose | Identify resources shared with external entities |
| Analyzes | S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues |
| Findings | Reports resources accessible from outside your account or organization |
| Policy validation | Validates IAM policies for best practices and security warnings |
| Policy generation | Generates policies based on CloudTrail activity (least privilege) |
On the Exam: "Identify S3 buckets that are publicly accessible" → IAM Access Analyzer. "Generate least-privilege IAM policies" → IAM Access Analyzer with CloudTrail.
A company wants to allow developers to create IAM roles for their Lambda functions but prevent them from creating roles with administrative privileges. What should they use?
An organization with 50 AWS accounts needs employees to sign in once and access any account based on their job function. Which service should they use?