3.3.1. Identity and Access Management (IAM, Organizations, SCPs, Identity Center, Federation)

💡 First Principle: The cornerstone of cloud security is granular control over who can access what resources and perform what actions, enforced by a robust identity management system founded on the principle of least privilege.

Scenario: A large enterprise with a multi-account AWS environment wants to enable its developers to securely access resources across different development accounts without managing individual "IAM users" in each account. They also need to enforce a corporate policy that prevents any developer from launching expensive or non-compliant "EC2" instance types across all development accounts.

Identity and Access Management ("IAM") is paramount for securing your AWS environment.

• "IAM Users": Represents individual human identities requiring persistent AWS credentials. Best practice is to use them with "MFA" and discourage long-term access keys.
• "IAM Roles": Grant temporary, limited-privilege permissions to trusted entities (human or machine).
  • Practical Relevance: Used for cross-account access, "EC2 instance profiles", "Lambda function execution roles", and federation. Preferred over "IAM users" for programmatic access.
• "IAM Policies": JSON documents defining permissions.
  • Practical Relevance: Apply principle of "least privilege" (grant only necessary permissions). Can be "identity-based" (attached to users/roles) or "resource-based" (attached to "S3 buckets", "SQS queues").
  • Organization-wide resource policies: In a bucket policy, the global condition key aws:PrincipalOrgID allows any principal from accounts in the Organization (no policy edits as accounts join), and the policy variable ${aws:PrincipalAccount} can scope each account to its own prefix (for example logs/${aws:PrincipalAccount}/*), giving per-account write access into a central log bucket without hardcoded account IDs.
• "AWS Organizations": Centralized management for multiple AWS accounts.
  • Practical Relevance: Consolidates billing and allows "Service Control Policies (SCPs)" to set maximum permissions for all "IAM users"/roles in member accounts, acting as preventative guardrails (e.g., deny specific high-risk actions across the entire organization).
  • How SCPs behave: SCPs never grant permissions; they filter them. An action needs an Allow in IAM and an Allow in every SCP from the root down to the account, and an explicit Deny at any level wins (an Allow at the account level cannot override a parent Deny). They apply to every IAM user and role and to the root user of member accounts, but not to the management account and not to actions performed through service-linked roles. Action names in policies are case-insensitive.
• "AWS IAM Identity Center (SSO)": Centralizes access management to multiple AWS accounts and business applications from a single sign-on portal.
  • Practical Relevance: Simplifies multi-account access for users, integrates with corporate directories ("Active Directory", "Okta"), and provides a unified authentication experience.
• Identity Federation ("SAML 2.0", "OIDC"): Allows users to sign in with corporate credentials and assume temporary "IAM roles" in AWS.
  • Practical Relevance: Eliminates the need to create and manage separate "IAM users" for every employee, reducing credential sprawl and improving security.

Visual: IAM, Organizations, Identity Center, Federation

Policy Layers, Cross-Account Access and Federation Details:

• Where SCPs attach and what they are for: An "SCP" attaches to the organization root, an "OU" or a member account, never to an individual IAM user or role. Because SCPs do not restrict the management account, attaching one to that account does not reach the member accounts; attach it to the root or to the "OU" that holds them. Typical uses: deny actions outside approved Regions (aws:RequestedRegion condition), deny resource creation that lacks a required tag (aws:RequestTag condition), deny stopping "CloudTrail" or deleting the "GuardDuty" detector, and deny turning off S3 Block Public Access (account-level Block Public Access does the blocking; the SCP stops administrators switching it off). An "SCP" deny also overrides a correct trust policy and identity policy, which is a common cause of an AccessDenied on sts:AssumeRole.
• Permissions boundary: A managed policy set on one user or role as the maximum its identity-based policies can grant (effective permissions = identity policy and boundary). It works inside a single account and is the tool for safe delegation: let a junior administrator call iam:CreateRole only when the iam:PermissionsBoundary condition names the approved boundary, so every role they create is capped. Use an "SCP" for organization-wide limits and a boundary to cap a particular principal or delegate within one account.
• Cross-account access with roles: Two grants are needed: a role in the target account whose trust policy names the caller's account (or role) and whose permissions policy allows the work, and an identity policy in the caller that allows sts:AssumeRole on that role's ARN. "STS" returns temporary credentials, and the target account revokes access by editing the trust policy; no network path (peering, "Transit Gateway") is involved because "STS" is an API call. An EC2 application acting in other accounts uses its instance role with sts:AssumeRole on each target role. A resource-based policy (S3 bucket policy, KMS key policy) can instead grant a foreign principal directly. iam:PassRole is a different permission: it lets a principal hand a role to an AWS service (for example when launching an instance or function with that role) and is not what a process needs to assume a role itself.
• Workforce federation: "IAM Identity Center" is the central choice for many accounts in an Organization: connect "Active Directory" or an external SAML IdP (Okta, Entra ID), assign permission sets to users or groups per account, and people get a portal plus temporary credentials for console and CLI with no IAM users and no per-account setup. A per-account IAM SAML identity provider plus roles (AssumeRoleWithSAML) must be repeated in every account, so it fits a single or standalone account that cannot use Identity Center. For a non-SAML OIDC identity (a CI server, an on-premises tool), create an IAM OIDC identity provider and a role trusting it; the caller uses AssumeRoleWithWebIdentity for short-lived credentials instead of long-lived access keys. "RAM" shares resources, not identities.
• Customer-facing identities: "Amazon Cognito user pools" are a managed user directory for app sign-up and sign-in (passwords plus social, SAML or OIDC sign-in) that issue JWT tokens, not AWS credentials. "Cognito identity pools" exchange a token (from a user pool, Google, Facebook and others) for temporary AWS credentials through "STS", mapped to an IAM role; policy variables such as the Cognito identity ID scope each user to their own S3 prefix or DynamoDB items. One IAM user per end user does not scale.
• Directory Service: "AWS Managed Microsoft AD" is a real, fully managed Active Directory in AWS with the highest application compatibility and support for trusts (including forest trusts) with on-premises AD; use it when AWS workloads need AD or when moving AD to AWS. "AD Connector" is only a proxy that forwards sign-ins to the existing on-premises AD and stores nothing in AWS; use it to keep on-premises AD as the single source of truth with no synchronization. "Simple AD", a small Samba-based directory without trusts, is no longer open to new customers, so new designs use one of the two options above. Cognito serves application users and Identity Center serves AWS access; neither is a directory for domain-joined servers.
• Multi-account structure: Separate member accounts grouped in "OUs" are the strongest isolation boundary for dev, test and prod (separate IAM scope, per-account billing visibility, per-OU "SCP" guardrails); VPCs, IAM groups or Regions inside one account isolate far less. "AWS Control Tower" automates the landing zone (OUs, log archive and audit accounts, guardrails); its mandatory controls, implemented as SCPs and "Config" rules, cannot be turned off by member accounts and protect the centralized logging and configuration it sets up.
• Root user and keys: Enable MFA on the root user, delete its access keys and use it only for tasks that require it. Applications use roles (for example EC2 instance profiles) for temporary credentials, never access keys in code.

⚠️ Common Pitfall: Granting overly broad permissions (e.g., *.*) for convenience. This dramatically increases the blast radius if an identity is compromised. Always start with zero permissions and add only what is explicitly required.

Key Trade-Offs:

• Granularity vs. Management Overhead: Highly granular "IAM policies" are more secure but can be more complex to manage. Using "IAM groups" and well-structured roles helps balance this.

Reflection Question: How would you combine "AWS IAM Identity Center (SSO)", cross-account "IAM Roles", and "AWS Organizations Service Control Policies (SCPs)" to meet the requirements of a large enterprise for centralized access management and preventative governance, specifically preventing developers from launching non-compliant "EC2" instance types across all development accounts?