Cloud IAM Fundamentals: Users, Roles and Least Privilege

Identity is the real perimeter

In a data centre, the wall around the building did a lot of security work. In a cloud account there is no wall. Every server, bucket and database is reachable through an API endpoint on the public internet, and the only thing standing between a request and your infrastructure is whether the caller can prove who they are and whether the policy engine says yes.

That is what Identity and Access Management does. IAM is the service that answers two questions on every single API call: who is asking, and are they allowed. Get it right and a leaked credential is an annoyance. Get it wrong and the same credential is a full compromise.

This guide covers the building blocks that all major providers share, the naming differences between them, and the practical route to least privilege that does not stall your team on day one.

Four building blocks, everywhere

Principals

A principal is anything that can make a request. Humans are one kind: engineers, contractors, finance staff pulling billing exports. Workloads are the other kind, and they usually outnumber the humans. An application server, a CI runner and a scheduled job all need identities of their own.

Credentials

Credentials are the proof. Passwords with a second factor for humans, and for workloads either long lived access keys or, far better, short lived tokens issued automatically to the machine. That distinction matters more than almost anything else in this article.

Policies

A policy is a written statement of allowed actions on named resources, often with conditions such as source network or required tags. Policies are evaluated on every call, and an explicit deny beats any allow.

Roles

A role is a set of permissions that a principal temporarily becomes rather than permanently holds. Roles are how you avoid handing out standing power. A developer assumes a read only role most of the day and a write role only when a change is planned.

The same ideas under different names

Vocabulary is the first obstacle. The table lines up equivalent concepts so that documentation from one provider stops reading like a foreign language.

Notice the bottom row. Hyperscalers give you a hierarchy where a restriction set high up cannot be undone lower down. Smaller platforms trade that away for simplicity, which is a genuine reason to keep separate projects for separate clients. The AWS versus DigitalOcean comparison covers how that trade-off feels in daily use.

Reaching least privilege without freezing the team

Least privilege means a principal holds exactly the permissions its job requires and nothing more. Stated that way it sounds obvious. In practice teams grant broad administrative access on day one because deadlines are real, then never narrow it.

The workable path is iterative rather than perfect. Start a new workload with a deliberately generous role in a non production environment, let it run through a full cycle including the monthly and quarterly jobs, then read the access logs to see which actions were actually called. Write the narrow policy from that evidence and swap it in.

Two habits keep the result from drifting. First, attach permissions to groups and roles rather than to individuals, so joining a team grants the right access automatically and leaving revokes it. Second, review privileged assignments on a fixed schedule and remove anything nobody can justify out loud.

Amazon publishes a detailed list of practices worth reading before you design your first policy set, in the IAM security best practices guide. Google covers the equivalent ground in its Cloud IAM overview.

Prefer roles to long lived keys

A static access key is a password that never expires, travels in plain text through config files, and works from anywhere on the internet. Many publicised cloud incidents begin with one of these turning up in a repository, a container image or a log line.

The alternative is an identity the platform issues to the machine itself. An instance assumes a role and receives a token valid for a short window, refreshed automatically. Nothing sensitive is ever written to disk, and a stolen token expires on its own.

The same idea covers pipelines. Modern CI systems can exchange a signed workload token for cloud credentials through OpenID Connect, which removes the need to paste keys into a settings page. Where a static key genuinely cannot be avoided, scope it to one task, restrict it by source address if the provider supports conditions, and put a rotation date in the calendar. Our article on managing API keys and secrets goes through the storage and rotation mechanics.

Failure patterns worth recognising

• Daily work performed as the root or global administrator identity instead of a scoped role. Root exists to create the first administrator and to handle a handful of account level tasks, nothing else.
• A wildcard policy granting all actions on all resources, added to unblock a deployment and never revisited.
• Shared logins for a team, which destroys attribution. When the audit log says an action was taken by an identity that five people use, the log tells you very little.
• Service accounts created for a proof of concept, granted broad rights, and left active after the project ends.
• Permissions granted directly to individuals rather than through groups, so nothing is revoked when someone changes teams.
• No second factor on the identities that can change IAM itself. Enforcing multi-factor authentication on cloud accounts matters most precisely for those identities.

Whether you run infrastructure on a hyperscaler or on a single virtual machine, this list applies. Buyers setting up a fresh environment through the AWS account listings should treat the first IAM configuration as part of the build, not as cleanup for later.

Questions people ask early