IAM Governance and Cross-Account Access

Engineering Problem

Cross-account access is often implemented with overly broad trust or policies. The lab shows how trust conditions, maximum-permission boundaries, time-limited sessions and external-access analysis combine without creating long-lived access keys.

Architecture

flowchart LR
  IdP[IAM Identity Center or Federated Role] --> STS[STS AssumeRole]
  MFA[MFA and External ID] --> STS
  STS --> Auditor[Cross-Account Auditor Role]
  Boundary[Permissions Boundary] --> Auditor
  View[ViewOnlyAccess] --> Auditor
  Analyzer[IAM Access Analyzer] --> Findings[External Access Findings]
  Trail[CloudTrail Role Preparation] --> Logs[CloudWatch Logs]

What I Implemented

• Created a permission boundary that defines the maximum approved service and region scope.
• Defined explicit trusted principals plus MFA and external-ID conditions for STS role assumption.
• Limited role sessions to one hour and attached view-only permissions inside the boundary.
• Enabled account-level IAM Access Analyzer for external-access findings.
• Added strict account password settings and CloudTrail-to-CloudWatch role preparation.

Important Technical Decisions

• IAM Identity Center is preferred for workforce access; the lab creates no IAM users or access keys.
• A permission boundary limits maximum permissions but grants nothing by itself.
• The sample external ID is not treated as a secret and must be replaced at runtime.
• SCPs and identity policies solve different governance problems.

Security Controls

• MFA, external ID and named principals restrict role trust.
• One-hour sessions reduce credential lifetime.
• Access Analyzer surfaces resource access from outside the account.

Reliability and Operations

• Policy Simulator and CloudTrail review are part of the verification approach.
• Explicit boundaries reduce unintended permission expansion during delegated administration.
• Regional deny behavior includes exceptions for global services.

Cost and Cleanup Guardrails

• IAM controls have limited direct cost, while CloudWatch Logs storage depends on retention and ingestion.
• The design uses a 90-day log-group retention value instead of unlimited storage.
• Access Analyzer scope and CloudTrail destinations should be reviewed before broad rollout.

Validation Evidence

The following local checks passed on 2026-08-13:

terraform fmt -check -recursive
terraform init -backend=false
terraform validate

Format, initialization and validation passed on 2026-08-13. No cross-account role assumption, Policy Simulator test, Access Analyzer finding review or complete CloudTrail trail deployment is claimed.

Delivery and Verification Runbook

1. 1

   Define approved principals and regions

2. 2

   Apply permission boundary

3. 3

   Require MFA and external ID

4. 4

   Assume one-hour role

5. 5

   Test allowed and denied actions

6. 6

   Review CloudTrail and Access Analyzer findings

7. 7

   Revoke or tighten unexpected access

Key Learnings

• Infrastructure evidence must distinguish code validation, plan review and live deployment.
• Security, reliability, cost and cleanup decisions should be documented before apply.
• A useful platform lab includes verification and rollback thinking, not only resource declarations.