IAM is the security perimeter of cloud-native organizations. Every API call, every data access, every deployment is an identity making a request. Getting IAM right means least privilege by default, auditability everywhere, and zero standing access as the north star.
Access Control Model Comparison
| Model | How it works | Granularity | Scalability | Complexity | Best for |
|---|
| RBAC (Role-Based) | Users assigned to roles, roles have permissions | Role-level | Good (for <100 roles) | Low | Most organizations, clear role hierarchies |
| ABAC (Attribute-Based) | Policies evaluate attributes (user, resource, environment) | Attribute-level | Excellent | High | Dynamic access, context-aware decisions |
| PBAC (Policy-Based) | Centralized policy engine evaluates rules | Policy-level | Excellent | High | Multi-cloud, complex compliance needs |
| ReBAC (Relationship-Based) | Access based on resource-to-user relationships | Relationship-level | Excellent | Medium | Document sharing, social, collaborative apps |
| ACL (Access Control List) | Per-resource list of allowed identities | Resource-level | Poor (doesn't scale) | Low | Simple file systems, legacy apps |
| MAC (Mandatory) | Labels/classifications enforced by system | Classification-level | Moderate | Very high | Military, government, regulated industries |
IAM Principles Checklist
| Principle | Description | Implementation |
|---|
| Least privilege | Grant minimum permissions required | Start with zero, add as needed; review quarterly |
| Separation of duties | No single identity can complete a critical workflow alone | Require multi-party approval for production changes |
| Zero standing access | No permanent privileged access | Just-in-time (JIT) access with time-bound elevation |
| Defense in depth | Multiple layers of access control | Network + IAM + application-level authorization |
| Assume breach | Design as if perimeter is already compromised | Micro-segmentation, continuous verification |
| Auditability | Every access decision is logged and reviewable | CloudTrail, audit logs, SIEM integration |
| Credential rotation | Secrets and keys have a defined lifetime | Auto-rotation via Vault, AWS Secrets Manager |
| MFA everywhere | Multi-factor for all human access | Hardware keys for admins, TOTP minimum for all users |
Multi-Cloud IAM Mapping
| Concept | AWS | GCP | Azure | Kubernetes |
|---|
| Identity provider | IAM Users / SSO | Cloud Identity / Workspace | Entra ID (Azure AD) | ServiceAccount / OIDC |
| Role / principal | IAM Role | IAM Role (roles/) | App Registration / Managed Identity | ClusterRole / Role |
| Policy attachment | Policy → Role → User/Group | Role → Member binding | Role assignment → Principal | RoleBinding / ClusterRoleBinding |
| Service identity | IAM Role for service | Service Account (GCP SA) | Managed Identity | Kubernetes ServiceAccount |
| Workload identity | IRSA (IAM Roles for SA) | Workload Identity Federation | Workload Identity Federation | Projected SA tokens |
| Temporary credentials | STS AssumeRole | STS (short-lived tokens) | Managed Identity tokens | TokenRequest API |
| Permission boundary | Permission Boundary policy | Organization Policy | Azure Policy | OPA / Kyverno |
| Cross-account/project | Cross-account roles | Cross-project IAM | Cross-tenant / Lighthouse | Cluster federation |
| Policy language | JSON (IAM Policy) | YAML (IAM bindings) | JSON (ARM/Bicep) | YAML (RBAC manifests) |
Service Account Management Matrix
| Aspect | Best practice | Anti-pattern | Risk if ignored |
|---|
| Naming | Descriptive: svc-billing-api-prod | Generic: admin, service-account-1 | Unauditable, impossible to trace |
| Key rotation | Auto-rotate every 90 days max | Static keys, never rotated | Compromised credentials persist |
| Scope | One service account per workload | Shared SA across multiple services | Blast radius of compromise |
| Permissions | Scoped to exact API actions needed | Admin/owner permissions | Lateral movement on compromise |
| Key storage | Vault, cloud secret manager | Environment variables, git repos | Credential leakage |
| Monitoring | Alert on anomalous SA behavior | No monitoring | Undetected compromise |
| Lifecycle | Decommission when workload is removed | Orphaned SAs accumulate | Unused attack surface |
| Human use | Never use SAs for human access | Sharing SA credentials among team | No individual accountability |
Audit Framework
| Layer | What to audit | Tool / source | Frequency | Retention |
|---|
| Authentication | Login attempts, MFA status, failed auth | IdP logs, CloudTrail | Real-time alerts | 1 year minimum |
| Authorization | Permission grants, role assignments | IAM change logs | Daily review | 2 years |
| Data access | Who accessed what data, when | CloudTrail data events, BigQuery audit | Weekly review | Per regulation (GDPR: purpose-bound) |
| Privilege escalation | Role assumption, temporary elevation | STS logs, JIT access logs | Real-time alerts | 1 year |
| Service accounts | Key usage, API call patterns | Cloud audit logs | Monthly review | 1 year |
| Policy changes | IAM policy modifications | Config change logs, SCPs | Real-time alerts | 2 years |
| Access reviews | Periodic validation of access rights | Identity governance tool | Quarterly | Indefinite |
IAM Architecture for Multi-Cloud
┌─────────────────────────────────────────────────────────┐
│ IDENTITY PROVIDER (IdP) │
│ Okta / Entra ID / Google Workspace │
│ SSO + MFA + SCIM │
└────────────────────┬────────────────────────────────────┘
│ SAML / OIDC
┌────────────┼────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ AWS │ │ GCP │ │ Azure │
│ IAM/SSO │ │ Workload │ │ Entra ID │
│ │ │ Identity │ │ │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Workload │ │ Workload │ │ Workload │
│ (EKS) │ │ (GKE) │ │ (AKS) │
└──────────┘ └──────────┘ └──────────┘
Cross-cutting: OPA/Cedar for unified policy evaluation
Audit: centralized SIEM (Splunk, Elastic, Datadog)
Resources
:::