Identity & Access Management

Cloud Platform Fundamentals

Chapter 6 · Identity & Access Management

Chapter 5 covered where traffic can go. This chapter covers who can do what, once they're already in — a genuinely different security layer, and per Chapter 1's shared responsibility model, IAM configuration sits squarely on the customer's side of the line, regardless of which service model (IaaS/PaaS/SaaS) is in use.

IAM's Core Building Blocks

  • Users — individual identities, typically representing a specific person.
  • Groups — collections of users that share the same set of permissions.
  • Roles — an identity assumed temporarily, often by a service or application rather than a person (its own dedicated section below).
  • Policies — documents (typically JSON) defining what actions are allowed or denied, on which resources.

Terminology diverges more here than in most of Chapter 2's mapping table: AWS uses IAM users/groups/roles/policies fairly directly; Azure uses Entra ID (formerly Azure AD) for users/groups, with separate Azure RBAC role assignments layered on top; GCP uses "members" (its umbrella term for any identity) combined with "roles," which in GCP specifically means a bundle of permissions assigned to a member — a subtly different use of the word "role" than AWS's assumable-identity meaning, worth keeping straight.

Roles — Why They're a Cloud-Native Concept

A role has no permanent credentials of its own — it's assumed temporarily, generating short-lived credentials that expire automatically. This solves a real, extremely common problem: an application running on a VM that needs to read from a storage bucket (Chapter 4) doesn't need a permanent access key embedded anywhere in its code or configuration at all — it can simply assume a role with exactly the permissions it needs, for exactly as long as it needs them.

Hardcoded credentials remain a serious, common real mistake
Embedding a permanent access key directly in application code or a config file — worse, committing it to a source repository — is a genuinely frequent real-world security failure, directly echoing this site's own pipelines1-5 ("a committed credential is compromised forever") and crypto1-11's key management chapter. Using a role instead of a static credential removes this risk entirely: there's no long-lived secret sitting in code for anyone to accidentally expose in the first place.

Roles are also used for cross-account access — letting a trusted identity in one account temporarily assume a role in another, without needing separate permanent credentials for every account involved.

The Principle of Least Privilege

This is exactly this site's own dbsec1-3 lesson, applied directly to cloud IAM: one identity per purpose, granular grants scoped to specific resources, and avoiding broad "allow everything" policies. The "just grant AdministratorAccess, it's easier" anti-pattern is genuinely common in practice, and genuinely risky — it turns any single compromised credential into a compromise of the entire account, rather than one narrow slice of it.

Real policy scoping goes further than just which actions are allowed — resource-level restrictions (access to this specific storage bucket, not every bucket in the account) and condition keys (restricting a grant by source IP address, time of day, or similar context) both narrow a policy's real-world blast radius considerably.

Authentication vs. Authorization in Cloud IAM

This site's own bc1-1 distinction applies directly: authentication is proving who you are (username and password, MFA, federated login); authorization is what that already-verified identity is actually allowed to do, determined by the policies attached to it.

This is a genuinely useful support-triage distinction — a "permission denied" or "access denied" error is an authorization problem, not a login problem, even though confused end users very commonly describe the two identically ("I'm logged in but I can't do X"). Recognizing that "logged in fine, action denied" almost always points at a missing or misconfigured policy — not a broken login — saves real troubleshooting time.

Multi-Factor Authentication (MFA)

Revisiting bc1-6's MFA coverage specifically for cloud console access: TOTP apps, hardware keys, and push notifications all apply here exactly as described there. One practice worth calling out as close to non-negotiable across every provider: enable MFA on the root/owner account specifically, since that account typically has unrestricted privileges that can't be scoped down by ordinary IAM policies the way a regular user's access can.

Root account MFA, restated plainly
Every ordinary IAM user's damage potential can be limited through least-privilege policies. The root/owner account is the one identity that typically can't be restricted that way — which is exactly why MFA on that specific account is treated as an absolute baseline, not an optional hardening step, across AWS, Azure, and GCP alike.

Federated Identity & Single Sign-On (SSO)

Rather than creating a separate cloud-native user account for every employee, organizations commonly federate identity from an existing corporate identity provider (Active Directory, Okta, or similar) via SAML or OIDC — so employees log in with their existing corporate credentials, and access is centrally managed from one place. Genuinely common in real enterprise environments; this course doesn't go deep on the protocol mechanics, but it's worth knowing the concept exists and why organizations reach for it.

A Support-Relevant IAM Troubleshooting Pattern

Facing an "access denied" error, the first question is exactly the AuthN-vs-AuthZ split above: can the user log in at all (authentication), or are they logged in fine but blocked from a specific action (authorization)? If it's authorization, the next question is: what policy is actually attached to this identity, and does it explicitly allow this specific action on this specific resource?

An explicit deny always wins
Across all three providers, policies aren't purely additive — if any attached policy contains an explicit deny for an action, that deny overrides an allow granted anywhere else, even a broad allow from a separate policy. A genuinely common, real troubleshooting trap is granting broad access via one policy, then being confused why a specific resource is still blocked — the answer is very often a separate, explicit deny sitting in another attached policy that nobody remembered was there.

Hands-On Exercises

Exercise 1

A user reports: "I'm logged in fine, but I get 'access denied' trying to do X." Is this an authentication or authorization problem, and what should be checked next?

📄 View solution
Exercise 2

Explain why using an IAM role (rather than embedding a permanent access key directly in application code) is the correct pattern for an application that needs to read from a storage bucket, and connect this to the real-world risk of hardcoded credentials.

📄 View solution
Exercise 3

A user has a policy granting them broad access to a service, but a separate, attached policy explicitly denies access to one specific resource within that service. What happens when they try to access that resource, and why?

📄 View solution

Chapter 6 Quick Reference

  • Users/groups/roles/policies — terminology diverges more here than most of Ch.2's map, especially GCP's "role" meaning
  • Roles are temporary, assumable identities with no permanent credentials — the correct pattern instead of hardcoded access keys (pipelines1-5, crypto1-11)
  • Least privilege — dbsec1-3's lesson applied to cloud IAM; resource-level scoping and condition keys narrow blast radius
  • AuthN vs. AuthZ (bc1-1) — "logged in but denied" is almost always an authorization problem, not a login problem
  • MFA on the root/owner account is close to non-negotiable — that account typically can't be scoped down by IAM policies at all
  • Federated identity/SSO — centralizing access via an existing corporate identity provider (SAML/OIDC)
  • An explicit deny always wins — policies aren't purely additive; one deny anywhere overrides an allow elsewhere
  • Next chapter: Databases in the Cloud — managed relational and NoSQL options across providers