Cloud IAM Best Practices — AWS, Azure & GCP

In this tutorial, you'll learn about Cloud IAM Best Practices. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Cloud IAM best practices help you enforce Least Privilege across AWS, Azure, and GCP by separating human roles from machine roles, using policy conditions, and regularly reviewing access.

What You Will Learn

How to design IAM architectures that minimize Blast Radius, automate access reviews, and prevent privilege escalation across all three major cloud providers.

Why It Matters

Over-permissioned identities are the root cause of 60 percent of cloud breaches. A single compromised developer key with full-admin access can expose an entire infrastructure.

Real-World Use

DodaTech's security scanner integrates with AWS IAM Access Analyzer to detect unused permissions across 200 accounts, cutting effective permissions by 80 percent in the first month.

Principle 1: Least Privilege

Every identity should receive only the permissions needed for its specific task, nothing more.

# AWS: Generate a fine-grained policy for reading only one S3 bucket
aws iam create-policy \
  --policy-name ReadOnlyMyBucket \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-data-bucket",
        "arn:aws:s3:::my-data-bucket/*]
      ]
    }]
  }'
# Output:
# {
#   "Policy": {
#     "PolicyName": "ReadOnlyMyBucket",
#     "Arn": "arn:aws:iam::123456789012:policy/ReadOnlyMyBucket"
#   }
# }

Principle 2: Separate Human and Machine Roles

Humans use interactive access. Machines use service accounts. Never share IAM users across people or applications.

# Azure: Create a managed identity for an application (not a user)
az identity create --name prod-app-identity --resource-group prod-rg
# Output:
# {
#   "clientId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
#   "principalId": "11112222-3333-4444-5555-666677778888",
#   "tenantId": "tenant-id-guid"
# }

Managed identities in Azure eliminate the need to store credentials in code. The platform rotates the identity automatically.

Principle 3: Use Conditions and Constraints

IAM conditions restrict permissions based on request context — source IP, time of day, MFA status, or resource tags.

# GCP: Add a condition that requires MFA for sensitive actions
gcloud iam service-accounts add-iam-policy-binding \
  prod-sa@my-project.iam.gserviceaccount.com \
  --member='user:admin@mycompany.com' \
  --role='roles/iam.serviceAccountAdmin' \
  --condition='expression=request.auth.claims.mfa_present == true,title=mfa-required'

Principle 4: Regular Access Reviews

Review all IAM policies quarterly. Remove unused roles, orphaned service accounts, and overly broad wildcards.

# AWS: Find unused IAM roles
aws iam list-roles --query 'Roles[?RoleLastUsed==null].[RoleName,CreateDate]' --output table
# Output:
# -------------------------------------------------
# |              ListRoles                        |
# +-------------------+--------------------------+
# | legacy-reader-rol | 2023-11-15T10:30:00Z    |
# | old-deployer-role | 2024-01-20T14:00:00Z    |
# +-------------------+--------------------------+

IAM Architecture Comparison

flowchart LR
  subgraph AWS
    A1[IAM User] --> A2[IAM Group]
    A2 --> A3[IAM Policy]
    A3 --> A4[AWS Resource]
  end
  subgraph Azure
    B1["User/Group"] --> B2[Azure AD Role]
    B2 --> B3[Role Assignment]
    B3 --> B4[Azure Resource]
  end
  subgraph GCP
    C1[Google Account] --> C2[IAM Role]
    C2 --> C3[Policy Binding]
    C3 --> C4[GCP Resource]
  end

Common Mistakes

1. Using root/admin accounts for daily work: Every cloud provider warns against this. Enable MFA on root accounts and use role-based access for daily administration.
2. Wildcard permissions without review: A "Action": ["*"] policy grants every current and future permission. Scope to specific actions.
3. Hardcoding service account keys: Keys embedded in code or config files leak. Use managed identities or IAM roles for instances instead.
4. Ignoring privilege escalation paths: If a role allows iam:PassRole combined with ec2:RunInstances, an attacker can launch an instance with an admin role attached.
5. Skipping cross-account trust reviews: Trust policies that allow external accounts to assume roles must be reviewed for abuse potential.

Practice Questions

1. What is the difference between an IAM user and an IAM role in AWS?
2. How do Azure managed identities improve security over service principal credentials?
3. What GCP feature allows you to restrict access based on MFA status?
4. Why should human and machine identities use different IAM paths?
5. How often should you review cloud IAM policies?

Challenge

Design an IAM architecture for a multi-team organization on AWS. Three teams need access: developers (read logs, deploy to staging), operators (manage EC2, RDS, and monitoring), and security (read all resources, modify IAM policies). Apply Least Privilege, separate human from machine roles, and add at least one condition per role.

FAQ