Core Cloud Architecture · Part 10 of 13

Identity and Access Management

Authentication and authorization for people, applications, and AI agents.

Networking decides what can reach what: an app server can reach a database, a function can read from a queue. Identity and access management (IAM) decides whether a given caller (people, applications, AI agents) is allowed to access specific resources.

Authentication vs. authorization

Authentication answers "who are you" by proving an identity, usually via a password, a certificate, a token, or a signed request. Authorization answers "what are you allowed to do," a separate question evaluated after authentication succeeds. A correctly authenticated identity can still be denied a specific action.

Identities: human and application

A human identity belongs to a person: an engineer with console access, a customer with an account. An application identity (a service account on GCP, an IAM role on AWS, a managed identity on Azure) belongs to a piece of software: an application server calling a database, a function calling another service. Application identities typically outnumber human ones, and deserve attention to what they're allowed to do, since a compromised application identity can be exploited automatically, at machine speed, with no human in the loop.

Identities: AI agents, a third category

An AI agent identity raises questions a service account's defaults don't answer. Audit needs to capture more than the API call the agent made: it should record the task or instruction that led to the call, because "the agent deleted this record" is a much less useful log line than "the agent deleted this record while handling the task 'clean up stale entries'." Scoping needs to be tighter and shorter-lived than a standing service-account role, because an agent's job may exist only for the duration of one task; a session- or task-scoped credential fits that shape. Revocation needs to isolate one agent's authority: killing a single misbehaving agent's ability to act shouldn't require disabling a service account that other, unrelated things share. AI Agents in the Generative AI Architecture series covers the authorization side in more depth.

Roles, policies, and least privilege

A role is, on GCP and Azure, a named bundle of permissions assigned to an identity. AWS uses the word differently: its permission bundle is a policy, and an IAM role is an identity that policies attach to. A policy is the document (usually JSON or a provider-specific equivalent) that spells out which actions are allowed on which resources, under which conditions. Role-based access control (RBAC) is the pattern of defining roles around job functions or application responsibilities ("read-only analyst," "checkout service") and assigning identities to roles, rather than managing permissions per-identity, which becomes unmanageable past a handful of people or services.

Least privilege is the governing principle underneath all of it: grant the permissions an identity needs to do its job, and no more. A service account that only ever reads from one storage bucket should have permission to read that one bucket, not read-write access to every bucket in the project. Least privilege sets how much damage a single compromised credential can do: a stolen credential with narrow permissions can only misuse those narrow permissions, while a stolen credential with broad ones can misuse all of them.

Workload identity

Workload identity lets a piece of software running in the cloud (a container, a function, a VM) obtain short-lived credentials automatically from the platform it's running on, tied to its own identity, instead of being handed a long-lived secret to authenticate with. This is what a Cloud Run service, a Lambda function, or an Azure Function's managed identity is doing under the hood: the platform vouches for the workload directly, based on where it's running, rather than the workload needing to prove itself with a static credential someone had to create and distribute.

Identity services

The problem with long-lived credentials

A long-lived credential (a static API key or password embedded in a config file, an environment variable, or worse, checked directly into source control) is a liability however carefully it was created. It doesn't expire on its own, so if it leaks (a misconfigured repo, a log line that shouldn't have printed it, a laptop that gets compromised), it keeps working until someone notices and manually revokes it. It's also usually shared across every place that needs the same access, so revoking it to contain one leak breaks everything else legitimately using it, forcing an uncomfortable choice between leaving a known-compromised credential live or breaking production.

Short-lived credentials and managed/workload identity mechanisms fix both problems at once: a credential that expires in minutes or hours limits how long a leaked copy is useful, and because it's issued per-workload rather than shared, revoking or rotating one doesn't require touching every other consumer. Workload identity also removes the manual rotation that long-lived keys require, and is now the default recommendation rather than an advanced hardening step. Third-party services that only accept an API key still need a stored secret, which is where a secrets manager (covered in Security Fundamentals in the Cloud) comes in.