Cloud Parts

Identity & access (IAM)

Who can do what, to which resource.

3 technologies on this page ↓
Live model
What you’re watchingThree identities call the same bucket. Policy evaluation allows the function role and the CI pipeline their specific actions, and denies the intern’s delete by default.

How it works

Identity and access management authenticates every caller (people, services, machines) and checks each API call against policies. Cloud IAM denies by default: a request succeeds only if some policy explicitly allows that action on that resource and no policy explicitly denies it. The goal is least privilege, where each identity has exactly the permissions its job needs.

Think of it as

Keycards in an office building. Your card opens the doors your job needs, and every swipe is logged.

Reach for it when

  • Every cloud account, from day one
  • Giving services short-lived role credentials instead of long-lived keys
  • Separating what developers, CI and production workloads can touch

Think twice when

  • * actions on * resources, even “temporarily”
  • One shared admin login for several people or services

A real example

A report function’s role allows s3:GetObject on reports/* and nothing more. When an intern’s account tries to delete objects in that bucket, the call fails with AccessDenied.

Technologies

Specific products, and what each does differently.

What each provider calls it

AWS
IAM, IAM Identity Center
Google Cloud
IAM
Azure
Microsoft Entra ID, Azure RBAC
Open source & others
Keycloak, Open Policy Agent

In code · json

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::acme-reports/reports/*"
  }]
}

Often confused with

AuthenticationSecrets managementAPI gatewaysVirtual private cloudsRemote access
Where it came from1992–2021

Access control used to be managed one user at a time: administrators wrote access control lists that spelled out, for each person, what they could touch. In a large organisation that was slow and costly. In 1992 Ferraiolo and Kuhn at the US National Institute of Standards and Technology (NIST) published a formal model for role-based access control (RBAC): permissions belong to roles that match job functions, and people are given roles. It became an ANSI standard in 2004, and by 2010 most users at organisations with more than 500 employees were on RBAC systems.

Cloud computing turned every server, bucket and database into an API, and every API call needed an authorization decision. AWS launched Identity and Access Management in 2011 with JSON policy documents that allow specific actions on specific resources under conditions, and deny everything else. Federation and short-lived credentials soon followed, and OAuth 2.0, published in 2012, standardised how an application gets limited access to another service on a user’s behalf.

In 2014 Google described BeyondCorp, which dropped the idea of a trusted internal network: every request is checked against the user and the device, wherever it comes from. Identity, rather than network location, became the main security boundary, and today workloads and CI jobs increasingly prove who they are with short-lived tokens instead of stored passwords and keys.

Why it’s built this way

Grant permissions to roles, not individuals
Listing permissions for each user individually didn’t scale. Tying permissions to roles means a new hire, a transfer or a departure is one change, and it is easier to see who can do what.
Deny by default
A request succeeds only if a policy explicitly allows it, so a forgotten rule fails closed. That is what makes least privilege, granting only what a job needs, enforceable.
Check identity, not network location
Perimeter security meant that once an attacker got inside the network, they had relatively easy access to everything. Checking each request’s user and device removes that soft interior.
Short-lived credentials over long-lived keys
A password or access key that never expires is valuable when it leaks. Temporary credentials, from AWS’s 2011 federation tokens to OIDC tokens for CI jobs, expire on their own.

Timeline

  1. 1992

    Ferraiolo and Kuhn formalise role-based access control at NIST

  2. 2004

    RBAC becomes the ANSI/INCITS 359 standard

  3. 2011

    AWS IAM launches with JSON policies; federation follows in August

  4. 2012

    OAuth 2.0 published as RFC 6749

  5. 2014

    Google’s BeyondCorp paper drops the trusted internal network

  6. 2019

    Google’s Zanzibar handles trillions of ACLs for Drive, YouTube and more

  7. 2021

    GitHub Actions jobs get short-lived cloud credentials via OIDC

Sources12

Improve this page on GitHub