Cloud IAM Fundamentals: Principals, Policies and the Least-Privilege Habit

Identity and access management is the control plane for everything else. Get it wrong and encryption, firewalls and monitoring become decoration, because an over-permissioned principal can simply turn them off.

The vocabulary differs between platforms; the concepts do not.

The four moving parts

Principals are things that can make requests: human users, machine identities, and sometimes entire services.

Resources are things requests act on: a storage bucket, a virtual machine, a database.

Actions are what can be done: read, write, delete, start, modify.

Policies bind them together, stating which principals may perform which actions on which resources, sometimes under conditions.

Roles beat long-lived keys

The single most valuable IAM habit is preferring assumable, short-lived credentials over permanent keys.

A long-lived access key is a password that never expires, is frequently committed to a repository by accident, and keeps working after the person who created it has left. A role assumed for a session issues credentials that expire on their own.

In practice this means:

• Applications on virtual machines get an attached role or service account, never an embedded key.
• CI pipelines use workload identity federation rather than stored secrets.
• Humans authenticate through single sign-on and assume roles, rather than holding per-account credentials.
• Where a long-lived key is genuinely unavoidable, it is inventoried, scoped narrowly and rotated on a schedule someone owns.

How policy evaluation actually resolves

The mental model that prevents most mistakes:

1. Default deny. Nothing is permitted unless something permits it.
2. An explicit allow grants access.
3. An explicit deny always wins, regardless of any allow.
4. Boundaries above can cap what is grantable below — Service Control Policies on AWS, organisation policies on Google Cloud, Azure Policy and management groups on Azure.

Point four explains the most confusing IAM symptom in existence: a principal with an apparently sufficient allow policy still being refused, because an inherited guardrail denies the action for everyone.

Least privilege that actually works

"Least privilege" fails when treated as a virtue rather than a process. The version that survives contact with a delivery schedule:

1. Start from a job, not a person. Define what a task needs, then grant that.
2. Grant to groups and roles, not individuals. Individual grants are invisible within a month.
3. Use conditions. Restrict by source network, by resource tag, by requiring MFA for destructive actions.
4. Review with data. Every platform reports which permissions were actually used. Remove what has not been exercised in ninety days.
5. Separate environments. Production and development should not share a permission boundary.
6. Make break-glass explicit. One heavily audited, alarmed emergency path is safer than permanently broad access "just in case".

The audit that matters on a new environment

Whenever you take over an environment, the IAM audit is the work that makes the hand-over real:

• List every human identity. Remove any you cannot account for.
• List every machine identity and every key it holds. Delete what is unexplained.
• Read role trust policies, not just permissions — a role can be assumable by a principal in someone else's account, and no password change affects that.
• Check inherited policies from any organisation, folder or management group above you.
• Confirm who holds billing administration, which is a separate permission from resource administration.
• Enable and verify audit logging across all regions before you rely on the environment.

This applies identically whether the environment is an AWS account, a Google Cloud account or an Azure account — only the menus differ.

Common failure patterns

• Wildcards everywhere. A policy granting all actions on all resources is not a policy.
• Keys in source control. Use secret managers and scan repositories.
• Shared logins. They destroy attribution; nobody can tell who did what.
• MFA on humans but not on privileged automation paths. The automation is the softer target.
• Permissions granted for an incident and never revoked. Temporary grants need an expiry someone enforces.

Frequently asked questions

Is IAM the same across providers? The concepts transfer; the syntax and scope model do not. Expect to relearn the details on each platform.

How often should keys be rotated? Prefer eliminating long-lived keys. Where one must exist, ninety days is a common baseline with an owner named for each key.

Does MFA protect against stolen API keys? No. API keys bypass interactive authentication entirely. That is precisely why short-lived credentials matter more than MFA alone.

What is the fastest meaningful improvement? Enumerate every long-lived key, delete the unexplained ones, and replace the rest with roles. It usually removes more risk than any other single change.

The credential rotation guide covers the operational routine, and the hardening checklist puts IAM in the wider sequence.