Identity & Access (IAM)

Identity and Access Management (IAM) controls who (identity) can do what (action) on which resource (resource) under what conditions (condition). AWS IAM uses JSON-based policies attached to users, groups, or roles; Azure uses Entra ID with RBAC role assignments scoped to management groups, subscriptions, resource groups, or resources; GCP uses IAM Bindings on resources. The principle of least privilege — granting only the minimum permissions needed — is the foundational security control.

Key Points

• AWS IAM Policy evaluation order: explicit Deny > explicit Allow > implicit Deny — a single Deny in any attached policy overrides any Allow.
• IAM Roles (not users) should be used for service-to-service authentication: EC2 instance profiles, ECS task roles, Lambda execution roles eliminate long-lived static credentials.
• AWS Service Control Policies (SCPs) in AWS Organizations are guardrails — they restrict what IAM policies in member accounts can grant, even for the root user.
• Azure Managed Identities (system-assigned or user-assigned) provide automatic credential rotation for Azure resources without storing secrets in code.
• GCP Workload Identity Federation allows Kubernetes service accounts (e.g., in GKE) to impersonate GCP service accounts via OIDC token exchange — no key files needed.
• Permission boundaries in AWS set the maximum permissions a user or role can have, even if attached policies grant more — used to safely delegate IAM administration.
• OIDC-based GitHub Actions integration (AWS OIDC provider, Azure Federated Credentials) allows CI/CD pipelines to assume cloud roles without storing cloud credentials as secrets.
• AWS IAM Access Analyzer identifies resources shared with external principals and validates policies against security best practices — run continuously in Security Hub.