Cloud IAM & Access Management

Cloud IAM is the most critical infrastructure decision you’ll make. A misconfigured IAM policy is the root cause of most cloud breaches — overly permissive roles, long-lived credentials, and unmonitored service accounts. This guide covers practical IAM architecture for AWS, GCP, and Azure.

---

Least Privilege Framework

Layer	What to Restrict	How
Identity	Who can access	Named users, service accounts, no shared creds
Action	What they can do	Specific API actions, not * wildcard
Resource	What they can touch	Specific ARNs/resources, not *
Condition	When/where they can act	IP range, MFA required, time window

AWS IAM Policy Example

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::company-data-bucket/team-alpha/*",
      "Condition": {
        "Bool": {"aws:MultiFactorAuthPresent": "true"},
        "IpAddress": {"aws:SourceIp": "10.0.0.0/8"}
      }
    }
  ]
}

---

Role Hierarchy

Organization Root
├── Admin Account (billing, org management)
│   └── OrgAdmin role (MFA + approval required)
│
├── Security Account
│   ├── SecurityAudit role (read-only across all accounts)
│   └── IncidentResponse role (break-glass, time-limited)
│
├── Production Account
│   ├── Developers → ReadOnly role
│   ├── SRE → OperationsRole (deploy, restart, investigate)
│   └── Service accounts → per-service minimal role
│
├── Staging Account
│   ├── Developers → PowerUser role
│   └── CI/CD → DeployRole (scoped to staging)
│
└── Development Account
    └── Developers → AdministratorAccess (sandbox)

---

Service Account Best Practices

Practice	Implementation
One per service	order-service-sa, not shared-service-account
Minimal permissions	Only the APIs the service actually calls
No long-lived keys	Workload identity (GKE), IRSA (EKS), managed identity (Azure)
Rotation	If keys required, rotate every 90 days automated
Monitoring	Alert on unused service accounts, unusual API calls

---

Anti-Patterns

Anti-Pattern	Problem	Fix
Action: "*"	Full access to every API	Enumerate specific actions
Resource: "*"	Access to every resource	Scope to specific ARNs
Shared service accounts	Can’t audit who did what	One SA per service, named users for humans
Long-lived access keys	Keys leaked in code/logs used forever	Workload identity, temporary credentials
No MFA on admin roles	Phished credentials = full access	MFA mandatory for all privileged roles
Permissions granted, never revoked	Permissions accumulate over years	Quarterly access review, auto-expire

---

Checklist

• Least privilege: actions + resources scoped, no wildcards
• MFA: mandatory for all human access to production
• Service accounts: one per service, minimal permissions
• No long-lived keys: workload identity or temporary credentials
• Cross-account access: via roles, not shared credentials
• Access review: quarterly, automated where possible
• Break-glass: documented, time-limited, audited
• CloudTrail/audit logs: enabled, monitored, alerted

---

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For cloud security consulting, visit garnetgrid.com. :::