Identity and Access Management (IAM)
Framework for defining who can access which cloud resources and how.
Last reviewed: July 25, 2026
What is IAM?
IAM controls authentication (who you are) and authorization (what you can do) in cloud environments. Every major cloud provider has an IAM system: AWS IAM, Google Cloud IAM, Azure Entra ID + RBAC.
Core concepts
- Principal — user, group, service account, or role
- Policy — document listing allowed/denied actions on resources
- Role — temporary credentials assumed by a principal (common for apps)
- Least privilege — grant only permissions required for a task
Example policy idea
A backup Lambda might receive permission to s3:PutObject on arn:aws:s3:::backups/* and nothing else — not full S3 admin access.
IAM vs application auth
| Layer | Handles |
|---|---|
| IAM | Infrastructure access (APIs, consoles, service-to-service) |
| OAuth / SSO | End-user login to your product |
Best practices (informational)
- Prefer roles over long-lived access keys for workloads
- Use groups and tags to manage permissions at scale
- Enable MFA for human accounts with console access
- Audit policies regularly — unused permissions accumulate over time
Federation
Many teams connect IAM to corporate identity providers (Okta, Azure AD) via SAML or OIDC so employees use single sign-on for cloud consoles.
Cost reality
IAM itself is free; sloppy IAM is the most expensive free service in the cloud. Most cloud breaches trace to leaked long-lived keys or over-broad roles — and the cleanup (forensics, rotation, disclosure) dwarfs any engineering time saved by AdministratorAccess everywhere.
What people get wrong
- Long-lived access keys in code, CI, and laptops. The #1 cloud credential leak; use roles and OIDC federation so credentials expire in minutes.
- Wildcard policies “to make it work.”
Action: *written at 2 a.m. survives for years; schedule access reviews and use analyzers that flag unused permissions. - Humans and workloads sharing identities. Service accounts used by people (or vice versa) destroy your audit trail exactly when you need it.
IAM as a Foundational Security Layer
IAM is often described as the foundation that most other cloud security controls are built on top of, since nearly every other security mechanism — encryption key access, network resource permissions, audit logging — ultimately depends on correctly identifying who or what is making a request and what they’re authorized to do. This is why IAM misconfigurations (overly broad permissions, unused but still-active credentials, missing multi-factor authentication requirements) are consistently identified in cloud security research as among the most common root causes of security incidents, and why cloud providers’ security best-practice guidance places heavy emphasis on IAM hygiene — least-privilege permissions, regular access reviews, and preferring temporary role-based credentials over long-lived static ones — as a first-priority security investment ahead of more specialized controls.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.