Design for Trust

Chapter Info

Calculating... Writing Progress: 80%

Modern systems cannot trust a request because it comes from inside a network, carries a password, or reaches the right endpoint. Every request must prove that the actor behind it is legitimate and allowed to act. Trust becomes explicit: identity is verified, authorization is scoped, access expires, and every action is traceable.

This chapter follows the shift from shared secrets to verifiable identity. It explains how cryptographic proof, federated identity, cloud IAM, short-lived credentials, controlled production access, AI agent identities, and Zero Trust all express the same design principle: trust should never be assumed; it must be proven, limited, and continuously re-evaluated.

Introduction

The Old Model: Trust the Perimeter [Perimeter Model]

For decades, systems were built on a simple mental model: a fortified perimeter separated a trusted "inside" from a dangerous "outside." Firewalls, VPNs, and private networks defined the boundary; anything that reached the internal network was largely assumed to be legitimate. Passwords, network addresses, and being "behind the firewall" served as sufficient proof of trust. This model was pragmatic for its era—when applications lived in one data center, employees worked from one office, and every device was managed by IT—but it quietly conflated location with identity.

The Perimeter Has Dissolved [Dissolved Perimeter] {1}

Modern systems no longer live inside a single perimeter. Applications run across multiple clouds, employees connect from anywhere, third-party SaaS holds critical data, mobile devices sit outside any managed network, and AI agents now act on behalf of humans across systems that never see each other. !!There is no longer an "inside" to defend—every request crosses a boundary, and every boundary needs its own trust decision.!! The old model has not merely eroded; it has become architecturally impossible to enforce.

The VPN Solution: Recreating the Wall Everywhere [The VPN Solution]

For a decade, the industry's answer was to recreate the perimeter in software. VPNs, IPsec tunnels, and site-to-site links wove offices, laptops, clouds, and data centers into one virtual private network. It improved confidentiality in transit, but it solved the wrong problem. !!Network location was still treated as evidence of trust: once a device crossed the VPN boundary it was "inside," and a single stolen credential could move laterally through the whole mesh.!! The failure was conceptual—the VPN tried to rebuild a trusted place, when what modern systems needed was to verify the identity, permissions, and context of every request.

Trust Must Be Proven, Not Assumed [Prove, Don't Assume] {1}

The response to a dissolved perimeter is not to build a bigger wall—it is to abandon the assumption that trust follows from location, network, or possession of a shared secret. In modern systems, !!trust becomes explicit: every request must prove who the actor is, what they are allowed to do, and that both facts are still valid right now.!! Nothing is trusted by default—not the caller, not the network, not the previous request. Each interaction stands on its own evidence, evaluated in the moment.

Zero Trust: The Architectural Stance [Zero Trust]

The introduction laid down the principle: trust must be proven, not assumed. Zero Trust turns that principle into four design moves. !!Network location grants nothing—being inside the perimeter is not evidence of anything!!. Every actor carries a verifiable cryptographic identity—carried by a certificate, a signed token, or a workload identity, depending on the layer. Every connection or request is authenticated and every action explicitly authorized against that identity. Contextual signals—device posture, location, behavior—can strengthen decisions for human access, but they are enrichments, not the foundation. Everything the chapter covers next—identity, cryptography, least privilege, ephemerality, audit—exists to make these moves possible.

Assume Breach [Assume Breach] {1}

Zero Trust designs the system as if the attacker is already inside—because eventually, they will be. !!Every control assumes the previous one failed!!, so the failure of any single layer is bounded, not catastrophic. This is not paranoia; it is realism. The question stops being "how do we keep them out?" and becomes "how do we limit what they can reach once they're in?".

Every Actor Has an Identity — Human, Machine, AI [Identity-Based Trust] {1}

Zero Trust starts by answering one question before any other: !!who is making this request?!!. Every actor—human, service, pod, node, AI agent—must carry a verifiable credential the receiver can validate without prior contact: a certificate, a signed token, a workload identity. Most requests in a modern system are not made by humans at all—a Lambda calls an API, a container queries a database, a CI/CD pipeline pushes an image, an AI agent acts on behalf of a user—yet each must have its own identity, its own scoped permissions, its own audit trail. Everything else Zero Trust does—continuous verification, contextual signals, PDP/PEP, microsegmentation—operates on top of this proven identity.

The Invention That Made This Possible — Asymmetric Cryptography [The Enabler] {1}

The shift from assumed to proven trust was not only a change of mind—it required a technology that did not exist for most of computing history. !!Asymmetric cryptography—a keypair where one half proves identity while the other half verifies it—is what turned "prove yourself" from a slogan into a mechanism.!! With it, an actor can sign a request that anyone can verify, without ever sharing a secret. Every mechanism in this chapter—signed tokens, mTLS, SPIFFE, passkeys, workload identity—rests on that single invention.

Continuous Verification, Not Once at Login [Continuous Verification] {1}

The old model verified at the front door and left the visitor alone for hours. Zero Trust re-verifies at every step—but "continuous" does not mean recomputing a risk score on every request. !!Verification is continuous because every request carries a cryptographic proof of identity—a certificate, a signed token, a workload credential—that must be valid, unexpired, and unrevoked, and is re-checked against policy each time!!. If the credential expires, the request fails. If it is revoked, the next call is denied. If the identity's permissions change, the next authorization check reflects it. Sessions do not confer trust; the credential carries it, and the policy re-evaluates it each time.

Separate Decision from Enforcement (PDP/PEP) [PDP & PEP]

Zero Trust splits authorization into two roles: the Policy Decision Point evaluates "should this identity be allowed to do this?", and the Policy Enforcement Point implements the answer. !!Decoupling the two does not mean calling a central service on every request!!. Policies can be authored centrally, distributed to enforcement points, cached locally, or evaluated inline by a service-mesh proxy, an API gateway, or the service itself. Whatever transport carries the identity—a certificate, a signed token, a workload credential—the PEP verifies it, and a local or distributed policy decides what it is allowed to do. What matters is that decision and enforcement stay conceptually separate—not that every check crosses the network.

Microsegmentation: Contain the Blast Radius [Microsegmentation]

In a Zero Trust design, the interior of the system is not one big trusted room—it is a grid of small cells, each authenticating and authorizing the next. When one workload is compromised, the attacker inherits the permissions of that workload only. Lateral movement becomes expensive, visible, and bounded. Segmentation used to be an IP-address problem; today it is an identity problem.

Rethinking Secrets in Modern Security [Rethinking Secrets]

Secrets have always been central to security—but their role is changing. For a long time, secrets were the only way to establish trust. Today, cryptography offers an alternative: proving identity without sharing anything that can be stolen or reused. This section explores the shift from security built on secrets to security built on verifiable identity.

Confidentiality vs Legitimacy [Confidentiality & Legitimacy] {1}

Confidentiality and legitimacy are often confused—but they address fundamentally different problems and require different solutions.

Confidentiality is about protecting information. Some data must remain hidden—personal records, financial transactions, trade secrets. The goal is to ensure that only authorized parties can access this information. If exposed, the damage is done.

Legitimacy is about proving identity and authority. Before accepting a request or granting access, a system must answer: who is asking, and are they allowed?

Confidentiality Requires Keys

Confidentiality requires controlling who can access information. In digital systems, this is typically achieved through encryption and the protection of cryptographic keys—the data itself can travel through any channel, provided only the intended parties hold the keys. Once information is exposed, however, confidentiality is lost forever: there is no way to undo disclosure. So the secret shifts from the data to the key, but it never disappears: something, somewhere, must remain protected.

Legitimacy: Keys as a Substitute for Identity [Key for Legitimacy]

Unlike confidentiality, legitimacy is not about hiding the message—it is about proving who wrote it. When someone—or a system—receives a request, two questions must be answered before acting on it: is the sender who they claim to be, and has the message been tampered with? The first is authenticity; the second is integrity. Only when both are verified can the system trust the request. The message and the proof do not need to be hidden; what must remain protected is the private key that creates the proof.

For centuries, the wax seal was the answer to both problems. Letters were sealed with melted wax stamped by a signet ring. The unique pattern proved authenticity—only the sender possessed that ring. And because broken wax cannot be restored, any tampering was immediately visible—proving integrity. Yet this method remained fragile—seals could be forged, wax carefully lifted and replaced—and it did not survive into the modern era.

In digital systems, without reliable methods to prove authenticity and integrity, legitimacy problems were treated as confidentiality problems. Messages were locked inside portable safes—encrypted containers requiring shared keys to open. If you possessed the key, you were assumed legitimate. But this was a substitution born from necessity, not design. Lacking the means to prove identity directly, systems fell back on secrecy as a proxy for trust.

Legitimacy: The Structural Limits of Secrets [Limits of Secrets]

The fundamental problem with shared secrets is this: both parties must possess the same key before they can communicate securely. But how do you share a secret securely if you don't yet have a secure channel? This chicken-and-egg problem plagued secure communication for centuries.

Beyond this, secrets do not scale. They must be stored, distributed, synchronized, rotated, and revoked across systems, humans, and machines. In distributed architectures, secrets inevitably spread and leak. The more systems interact, the more secrets circulate, and the larger the attack surface becomes. In highly connected environments, secrets are no longer a protection mechanism but a systemic risk.

Legitimacy: A New Paradigm—From Secrets to Proofs [Cryptographic Shift] {1}

For legitimacy, a fundamental shift moved security away from secrecy toward identity. Cryptography made it possible to prove who is speaking and that a message has not been altered, without ever sharing a reusable secret. Securing a message no longer depends on hiding it, but on verifying cryptographic evidence. Identity becomes the anchor of trust.

Identity-Based Security: The Foundation of the Cloud [Identity-Based] {1}

This paradigm shift reshaped modern architectures entirely. In the cloud, every actor has an identity, and every resource has an explicit identifier—machines, services, workloads, databases, storage buckets—each named and addressable by the platform. When one service needs to communicate with another, it no longer relies on a shared secret to prove legitimacy. Instead, the request is signed by the sender and verified by the receiver—independently, without a callback, without a shared key. Confidentiality is still handled separately (typically by TLS wrapping the request), but trust in who is speaking no longer depends on hiding anything: it depends on cryptographic proof of identity and integrity. This model is the foundation of cloud-native security.

Standard Identity and Access Management [Standard IAM]

Identity and Access Management (IAM) is the discipline that defines who or what is allowed to access which resources, under which conditions, and for how long.

IAM combines two core functions. Identity establishes who is making a request—a human, a service, a workload, or a device—using verifiable proof. Access management determines what that identity is allowed to do by evaluating permissions, policies, and context before granting access.

In modern systems, as explained in the previous section, IAM is not about hiding secrets but about verifying legitimacy. Identities are proven using cryptographic evidence, access is granted through explicit authorization rules, and permissions are typically time-bound and auditable.

It's essential to understand the fundamental concepts and standard protocols that form the foundation of modern identity and access management. These universal concepts and open protocols provide a common language that works across any system—regardless of cloud provider, platform, or organizational boundary.

We'll begin by exploring the core principles that drive modern identity management—the fundamental ideas that any protocol must address. Then we'll examine the standard protocols that implement these principles, both at the application layer and the transport layer.

IAM Core Principles [IAM Principles] {1}

Authentication and Authorization (Who/What) [AuthN & AuthZ] {1}

In any secure system, authentication and authorization are the two essential pillars of access control. Authentication answers the question "Who are you?" by verifying identity. Authorization answers "What can you do?" by determining permitted actions.

Authentication ensures that only legitimate users or services can access the system by verifying their identity. Common methods include passwords, tokens, multi-factor authentication (MFA), and biometric methods like fingerprint, facial recognition, and iris scanning.

Once authenticated, authorization determines what actions the authenticated entity is permitted to perform, based on assigned roles, permissions, and policies. These processes are critical for preventing unauthorized access and minimizing security risks by controlling who can do what within the system.

What Is Identity? [What Is Identity?] {1}

Identity is not a single attribute—it is a collection of facts that together characterize a person, a service, or a machine. A name alone does not define identity; many people share the same name. Identity emerges from the combination of attributes: name, date of birth, address, job title, department, physical traits, biometric data, organizational role, device fingerprint, or cryptographic keys.

In digital systems, identity is represented as a set of claims—statements about an entity that can be verified. A token might claim "this user is Alice," "she belongs to the engineering department," "she authenticated at 10:42 AM," and "this token expires in one hour." Each claim adds a dimension to identity. The more claims, and the more reliably they can be verified, the stronger the identity. Authentication is the process of verifying these claims; authorization uses them to make access decisions.

Authentication at Transport vs Application Layer [Auth Layers]

Network communication happens in layers—the OSI model defines seven, from physical cables to application protocols. For authentication, two layers matter most: the transport layer and the application layer. The transport layer handles the connection itself—establishing an encrypted tunnel between two machines. The application layer operates inside that tunnel, where HTTP requests, APIs, and business logic live. These are the two levels where identity can be verified, and understanding the distinction is essential for designing secure systems.

In a typical secure web application, the server proves its identity at the transport layer: when you connect to your bank's website, the server presents its certificate during the TLS handshake, and your browser verifies it—before any application data is exchanged.

The client proves its identity at the application layer: after the secure tunnel is established, you enter your password or the application sends an API key in HTTP headers.

This pattern remains the standard in modern security. However, we will see alternatives that move client authentication down to the transport level as well.

While authentication can occur at either layer, authorization—determining what an authenticated entity can do—typically happens at the application layer. Only the application understands the business context: which actions are permitted, on which resources, under which conditions. Network-level controls (firewalls, security groups) provide coarse authorization by restricting connectivity, but fine-grained permission decisions require application logic.

Delegate Authentication to a Trusted Third Party (Federation) [Federation] {1}

Federation means delegating authentication to a trusted Identity Provider. The application never sees the user's password—it simply trusts the IdP's assertion that the user is who they claim to be. Think of it like entering a partner's building with your company badge: you don't need to create a new badge—the building trusts your company to confirm who you are.

Without federation, every application maintains its own user database, implements its own login flow, and stores its own passwords. Developers reinvent the wheel repeatedly, and users juggle dozens of credentials. Worse, security is inconsistent—each implementation has its own vulnerabilities.

Federation solves this with centralization: a single place to enforce security policies, instant access revocation when someone leaves, complete audit trails, and users who maintain just one set of credentials. One identity provider can serve hundreds of applications—each one freed from building and securing its own authentication.

A Token Is Not a Password — It Is a Signed Claim [Token as Claim]

A token is not a password—its trustworthiness rests on a cryptographic !!signature!! from the Identity Provider that any system can verify independently, not on secrecy. Its contents are meant to be inspected: audience, expiry, claims. But a bearer token is still an operational secret while it lives: whoever holds it can replay it until it expires. So the discipline is different from a password—short lifetimes, audience binding, TLS-only transit, no logging, no long-term storage—but the token is not free to expose. Verifiable in structure, protected in use.

Prove Identity Without Sharing Secrets [Crypto Identity]

Cryptography makes it possible to prove identity without sharing any reusable secret. Instead of proving who you are with something you know (a password), you prove it with something you have (a private key) that generates verifiable signatures. The private key never leaves your system—you only send a signature that proves you possess it. Anyone can verify this signature using your public key, but no one can forge it without the private key.

This principle can be applied at both levels: at the transport level, mTLS and SPIFFE use certificates to authenticate machines; at the application level, WebAuthn and Passkeys authenticate users without passwords. In all cases, identity is proven through cryptographic evidence—not by transmitting secrets.

Prove Token Authenticity Without Callback [Stateless Verification]

When a service receives a token, how does it verify that it's legitimate? Traditional approaches require calling back to the issuer to validate every request—creating latency, dependencies, and a single point of failure.

Cryptographic signatures solve this by embedding all necessary information in the token itself, signed by the issuer. The receiving service can verify the signature locally using the issuer's public key—no callback required. This enables massive scalability: millions of requests can be verified without overwhelming a central authentication service.

The Principle of Time-Limited Access [Ephemeral Tokens] {1}

Access should never be permanent. Every token should have an expiration time. If a token is stolen, the damage is automatically limited—the attacker's window of opportunity closes when the token expires.

This principle transforms security from a static state to a continuous process. Instead of permanent API keys, use tokens that expire in minutes or hours. Instead of long-lived passwords, use session tokens that refresh automatically. The system constantly renews itself, and compromised credentials become useless with time. All modern identity protocols implement this by issuing short-lived tokens that must be refreshed regularly.

User-Centric Flows [User-Centric]

In distributed architectures, applications, APIs, and identity providers must cooperate without direct trust relationships between every pair. The solution is to place the user at the center. The user's browser becomes the integration point that shuttles between systems through HTTP redirects: each application redirects the browser to the Identity Provider, the IdP authenticates the user, then redirects back to the application with a proof of authentication. In modern OIDC, that proof is an authorization code (a short-lived, one-time reference) which the backend then exchanges server-to-server for the actual tokens—so the browser never handles the high-value tokens directly. Older SAML flows send the signed assertion back through the browser more directly. Either way, services stay decoupled—they don't need to trust each other, only the Identity Provider.

Prefer Server-to-Server for Sensitive Operations [Server-to-Server]

In user-centric flows, the browser establishes who the user is, but should not carry the privileges to act on the backend's behalf. Modern OIDC flows reflect this: the browser receives an authorization code, which the backend then exchanges for tokens over a server-to-server call—so the browser never touches the high-privilege credentials directly. The principle generalizes: !!infrastructure secrets, service-to-service credentials, and backend authority must not be entrusted to the client!!. User-centric authentication establishes identity; execution of sensitive operations happens server-to-server, where credentials can be safely contained. Backend systems authenticate to each other using strong, non-interactive mechanisms such as mutual TLS, workload identity, or OAuth client credentials, ensuring the client never holds or exercises privileges it doesn't need.

Application Layer Protocols [App Layer Protocols]

The following protocols operate at the application layer, handling user authentication, single sign-on, and delegated authorization through tokens exchanged in HTTP headers and redirects.

OIDC/SAML: Authenticate Users via a Trusted Third Party [OIDC & SAML]

Both OIDC and SAML implement the federation principle: rather than handling authentication directly, an application delegates the login to a trusted Identity Provider that issues a signed token. OIDC is the modern choice—JSON-based, designed for web and mobile applications, and dominant in cloud-native systems. SAML is the enterprise standard—XML-based, deeply embedded in corporate directories and B2B integrations, still ubiquitous for legacy and partner scenarios. Many organizations run both side by side; the choice depends on the ecosystem, not on which protocol is "better."

Cross-Substrate Identity Federation [Cross Substrate Federation] {1}

Cross-substrate identity federation uses the OIDC trust pattern from the previous section for cross-cloud workloads: a service in one cloud (e.g. AWS) accesses another (GCP, Azure) without long-lived passwords or static keys between platforms; the pattern works in reverse too. Providers establish a trust relationship via OpenID Connect (OIDC): the origin issuer signs tokens; the destination trusts that issuer and maps identities to local roles. The workload presents signed OIDC proof; the target validates it and issues short-lived credentials (STS-style or workload identity federation)—a visitor badge expiring in minutes or hours, so renewed access needs a new exchange. That avoids durable cross-cloud secrets, cuts manual key rotation for those links, and bounds damage if a token is intercepted.

SSO: Single Sign-On for Multiple Applications [SSO Pattern]

Single Sign-On introduces a session at the Identity Provider level that spans multiple applications. When you access the first application, you authenticate with the IdP and a session is created. When you access a second application, you're redirected to the same IdP—but this time, the IdP recognizes your existing session and issues a token without asking you to log in again.

The key insight is that SSO does not mean "one token for all apps." Each application receives its own token, specific to that application. What makes it "single sign-on" is the shared IdP session: you authenticate once, and subsequent applications receive their tokens automatically. This centralizes security controls—multi-factor authentication, anomaly detection, and access revocation all happen at the IdP. When someone leaves the organization, revoking their IdP session immediately locks them out of every connected application.

This is the foundation of enterprise application portals—a central page listing all company applications where users simply click to access any of them, without ever being asked to log in again.

OAuth: Let Someone Else Access Your Data Managed by a Third Party [OAuth]

OAuth addresses a specific scenario: you want to let an application access your data stored elsewhere, without giving that application your password. Think of a photo printing service that needs access to your cloud photos. You don't want to share your cloud password—you want to grant limited, revocable access.

The metaphor is a valet key: a limited key that lets the valet drive your car but not open the trunk. With OAuth, you authenticate directly with the service that holds your data, then authorize specific permissions for the requesting application. The application receives a time-limited token with only the access you approved—it never sees your password, and you can revoke access at any time.

OIDC is built on top of OAuth. While OAuth handles authorization (what an app can access), OIDC adds authentication (who the user is). Together, they cover both questions that modern applications need to answer.

WebAuthn/Passkeys: User Authentication Without Passwords [WebAuthn]

Modern security relies on temporary tokens—short-lived, scoped, and revocable. But to obtain these tokens, users must first prove their identity, traditionally by transmitting a password. This creates a vulnerability: even if the token is ephemeral, the password used to obtain it is not. It can be phished, leaked, or intercepted.

WebAuthn (and its user-facing implementation, Passkeys) eliminates this weakness using the same principle as mTLS, but at the application level. Instead of a password, your device holds a private key stored securely in hardware (a secure enclave, a YubiKey, or your phone). When you authenticate, you unlock the key locally with your fingerprint or Face ID, and the key signs a challenge from the server. Only the signature travels over the network—never the secret itself.

This is cryptographic identity for humans: prove who you are without sharing a secret. Just as mTLS eliminates API keys for machines, WebAuthn eliminates passwords for users. The principle is identical—asymmetric cryptography where the private key never leaves the secure environment.

Passkeys represent the future of user authentication. Major platforms (Apple, Google, Microsoft) now support them natively, and adoption is accelerating. The password—one of the oldest and weakest links in security—is finally being replaced by cryptographic proof.

Transport Layer Protocols [Transport Layer Protocols]

The following protocols operate at the transport layer, establishing machine identity through certificates during the TLS handshake—before any application data is exchanged.

TLS: The Encrypted Tunnel with Server Authentication [TLS]

Transport Layer Security (TLS) creates an encrypted tunnel between client and server, ensuring that data cannot be intercepted or modified in transit. During the TLS handshake, the server presents its certificate, proving its identity to the client. This is why your browser shows a padlock icon—TLS has verified you're talking to the real server.

In its most common deployment—classic HTTPS on the public web—TLS authenticates only the server: the server proves who it is, the client remains anonymous at the transport level, and any client authentication happens later at the application layer, through passwords or tokens sent inside the encrypted tunnel. TLS itself supports mutual authentication (see mTLS below), but the default HTTPS mode you meet on the web is one-sided.

mTLS: Mutual Authentication Without Sharing Secrets [mTLS]

Recall that in standard TLS, only the server proves its identity at the transport level—the client must still authenticate at the application level using passwords or API keys. Mutual TLS changes this by moving client authentication down to the transport level as well. Both parties present certificates during the TLS handshake, before any application data is exchanged.

This shift is significant for machine-to-machine communication. Instead of configuring API keys in your application, managing their rotation, and transmitting them with every request, identity is proven cryptographically at connection time. No secrets in HTTP headers, no credentials to leak in logs. The application layer no longer handles authentication—it's already done. This is why service meshes and zero-trust architectures rely heavily on mTLS: it provides strong, automatic authentication for every connection without requiring applications to manage credentials at all.

SPIFFE: Cross-Platform Workload Identity [SPIFFE] {3}

In traditional environments, a service's identity was often tied to its network location or static credentials. But in modern architectures where workloads run across Kubernetes clusters, virtual machines, and multiple clouds, this approach breaks down. SPIFFE provides a universal identity framework for workloads, regardless of where they run.

The core idea is simple: every workload receives a cryptographic identity that can be verified anywhere. Whether a service runs in AWS, Azure, on-premises, or moves between environments, its identity remains consistent and verifiable. This enables organizations to apply the same authentication and authorization policies across their entire infrastructure, eliminating the complexity of managing different identity systems for different platforms.

The Cloud IAM Abstraction [Cloud IAM Abstraction]

Cloud providers have created a powerful abstraction layer for identity and access management that works consistently across all their services. Instead of implementing various protocols and managing separate identity systems for each service, cloud IAM provides a single, consistent model where every resource, user, and service is part of the same identity framework.

IAM Services [IAM Services] {1}

Each major cloud provider packages identity and access management into a single, centralized service: AWS IAM, Azure Entra ID (formerly Azure AD), and Google Cloud IAM. Rather than managing authentication and authorization separately for each cloud service, this unified service governs the entire platform. While the specific APIs and terminology differ between providers, they all implement the same core model: identities, policies, roles, and permissions.

IAM acts as the control plane that enforces trust across users, services, and infrastructure. Every access decision—whether a user accessing a console, a service calling an API, or an application reading from storage—flows through this central authority.

Every Actor and Resource Is Explicitly Identified [Actors & Resources] {1}

In the modern security paradigm, we have moved from a world of perimeters (inside = trusted, outside = untrusted) to a world of explicit identifiers. Cloud IAM draws a sharp line between two roles: principals—the actors that make requests and can be authenticated—and resources—the objects those requests target, addressed by a unique identifier but not themselves authenticating anything. Both need names; only principals need identities.

Principals act. A Lambda function, an EC2 instance, a Kubernetes workload, a human user, a service account—each is a principal with a cryptographically verifiable identity issued by the platform (through instance metadata, workload identity, or federated tokens). Principals are the "who" in every access decision. Resources are targets. An S3 bucket, a database, a secret, a queue, an API endpoint—each has a globally unique identifier that policies can reference, but a bucket does not "log in" or "prove who it is." Resources are the "what" in every access decision.

Cloud Provider	Naming Format	Example
AWS	ARN (Amazon Resource Name)	arn:aws:s3:::my-bucket
Azure	Resource ID	/subscriptions/{sub}/resourceGroups/{rg}/providers/...
GCP	Resource Name	projects/{project}/buckets/{bucket}

This split has a profound implication: for many internal cloud interactions, the principal's identity is provided by the platform rather than embedded in the application. When a Lambda calls S3, the calling identity is established by the platform through mechanisms like instance metadata services, workload identity, or signed requests—so the application does not have to embed credentials. Policies then reference both sides explicitly: which principal, doing what action, on which resource, under which conditions. Audit logs capture the full quadruple. Infrastructure-as-Code manages access at scale by referencing principals and resources by their canonical names.

IAM: Authentication Recommendations [AuthN Recommendations]

Federated authentication is the preferred approach for human-to-service authentication because it enables single sign-on, centralizes identity management, and eliminates the need to maintain separate credentials across multiple systems. For machine-to-machine authentication between services, direct authentication using certificates or tokens is more suitable—it provides automated, cryptographic verification without requiring human interaction or external identity providers.

These authentication mechanisms build on the standard identity protocols (OAuth 2.0, OIDC, SAML, mTLS) covered in the Standard Identity and Access Management section.

IAM: Authorization [IAM Authorization] {1}

Once identity is verified through authentication, authorization determines what that identity can do. IAM manages authorization through policies that define permissions—explicit rules specifying who can perform which actions on which resources.

Policy documents specify the resources (databases, storage, APIs), the actions allowed (read, write, delete), and the conditions under which access is granted (time, location, network).

While policies can be attached directly to users, organizations typically create roles (like "Admin", "Developer", "DataScientist") that group related policies together. Users are then assigned to one or more roles, inheriting all associated permissions. When users need to act under a specific role's permissions, they "assume" that role for their session, allowing them to switch between different permission sets based on the task at hand.

IAM: Role-Based Authorization [Role-Based AuthZ] {1}

Role-based authorization is the most widely used approach today—it's simple, explicit, and works well for most organizations. It defines roles (like "Developer", "Support", "Admin"), assigns users to them, and permissions follow automatically. This makes it ideal for systems where access patterns are relatively static and easy to categorize.

This role-based approach is commonly referred to as RBAC (Role-Based Access Control).

IAM: Attribute-Based Authorization [Attribute-Based AuthZ]

However, another alternative is to use Attribute-Based Access Control (ABAC), which bases authorization on attributes—characteristics of the user (department, role, clearance level), the resource being accessed (classification, owner, location), and the environment (time of day, network, device).

Instead of fixed roles, ABAC evaluates multiple attributes dynamically to make fine-grained access decisions. This enables policies like "allow access to financial records only during business hours from corporate networks for users in the finance department with active employment status."

While ABAC introduces complexity, it offers far greater flexibility for organizations that require context-aware policies and precise control. ABAC is particularly valuable when access requirements depend on multiple factors that change frequently, making it impractical to create and manage all the necessary roles.

IAM Best Practices [IAM Best Practices]

Beyond understanding how IAM systems work, organizations must follow fundamental security principles that minimize risk and strengthen their overall security posture. These best practices apply regardless of whether you use role-based or attribute-based authorization.

Least Privilege Principles [Least Privilege] {1}

The Principle of Least Privilege (PoLP) is a key security concept in which users, applications, and systems are granted the minimum levels of access—or permissions—needed to perform their tasks. The goal is to limit potential damage in the event of an accident or security breach.

This principle is common sense in daily life: when giving your car to a mechanic, you remove unnecessary keys from the keychain—no need to include your house keys.

Applying the Principle of Least Privilege means creating highly specific roles and permissions tailored to exact needs. For users, this means roles like "read-only", "support", "admin", "developer"—each with only the permissions required for that function. For services communicating with other services, the same principle applies: each service receives only the specific permissions needed for its operations, nothing more. This extends to tokens as well: a token should grant only the permissions needed for a specific task and be valid only for the intended service—so even if compromised, the damage is limited.

Everything is Forbidden By Default [Default Deny] {1}

Everything is forbidden by default. Unless explicitly allowed, all access, actions, and operations are denied. This approach ensures that all permissions are intentional and explicit—you must consciously grant access rather than accidentally leaving it open.

Adopting the "everything is forbidden by default" approach strengthens security posture by proactively preventing unauthorized actions and ensuring that all access is intentional and controlled. This approach also minimizes the blast radius and reduces the attack surface, limiting potential damage from security breaches.

Time-Bound Access [Ephemeral Access] {1}

One of the fundamental security principles discussed earlier is minimizing exposure—keeping resources ephemeral and short-lived reduces the attack surface and limits the window of opportunity for attackers. Applied to Identity and Access Management, this principle translates to time-bound access: restricting access to resources for specific time periods rather than granting permanent permissions.

Users should never possess perpetual keys. Instead, access should be granted for a limited duration, ensuring that no one has indefinite access to cloud environments or sensitive systems. Once the specified time frame expires, access is automatically revoked.

For machine-to-machine authentication, the same time-bound principles apply. Services should use short-lived credentials with automated renewal, ensuring that even if compromised, the window of exposure is minimal.

External Material

AWS:SEC02-BP02 Use temporary credentials

Separation of Duties [Separation of Duties] {1}

Separation of Duties (SoD) is a key internal control principle aimed at preventing errors and fraud by dividing tasks and responsibilities among multiple individuals. This ensures that no single individual has control over all aspects of any critical function or process, helping prevent abuse of power and reducing the risk of errors or fraudulent activities.

When you disable branch protection for administrators in GitHub and bypass the requirement of having a reviewer, you transgress the principle of separation of duties.

Chain of Control: Structured Approval Process [Chain of Control]

Separation of Duties is essential to minimize risks by ensuring that no individual has complete control over critical processes. However, the next step is to implement a Chain of Control for approving any risky changes. This flow must be configured to align with the organization's policies and risk tolerance. For example, a typical process might involve initiating the change by the responsible individual, reviewing it with a peer, and obtaining final approval from a manager. By configuring such a flow, the organization ensures accountability, consistency, and transparency. This approach helps prevent unauthorized or poorly vetted changes, promoting collaboration and careful evaluation, while balancing agility with security.

Traceability [Traceability]

Maintaining traceability involves continuously monitoring, logging, and auditing all activities and changes within a system to ensure accountability. By keeping a detailed record of who did what and when, organizations can track and trace any actions taken across their infrastructure, making it easier to detect anomalies, identify potential security threats, and meet compliance requirements. These logs help in quickly investigating incidents, ensuring transparency, and providing valuable insights for improving security measures. Effective traceability also supports proactive responses to issues, minimizing downtime and mitigating risks before they escalate.

Breakglass Mechanism [Breakglass] {3}

A break-glass mechanism is a security process used to provide emergency access to critical systems or data under exceptional circumstances, such as during a system failure or urgent incident. The term comes from the idea of "breaking the glass" to access something that is typically secured. In cybersecurity and IT operations, break-glass mechanisms are designed to allow temporary elevated privileges without compromising long-term security protocols.

This mechanism ensures that authorized personnel can bypass strict controls in emergencies—such as gaining administrative access to resolve a critical outage—while still maintaining accountability through auditing and monitoring. All actions performed using break-glass access are typically logged to ensure traceability, and permissions granted are often revoked automatically once the task is completed or after a predefined time limit. This helps mitigate the risks of insider threats or privilege misuse.

Secrets Management [Secrets Management]

Secrets—API keys, database passwords, encryption keys, certificates, and tokens—are the sensitive credentials that applications need to access resources and authenticate with services. Managing secrets securely is one of the most critical and challenging aspects of cloud security. Poor secrets management leads to credential exposure, data breaches, and compliance violations. Modern organizations must adopt comprehensive strategies that minimize secrets where possible and manage necessary secrets through centralized, automated systems.

The Secrets Sprawl Problem [Secrets Sprawl] {1}

Organizations struggle with secrets proliferation: credentials scattered across code repositories, configuration files, environment variables, CI/CD systems, container images, and developer laptops. Each location represents a potential exposure point. Developers frequently hard-code credentials for convenience, secrets get committed to version control accidentally, and credential rotation becomes impossible when you don't know where all copies exist. This sprawl creates unmanageable security debt where a single leaked credential can compromise entire systems.

The Secrets Management Hierarchy [Secrets Hierarchy] {1}

Not all approaches to secrets management are equal. Organizations should adopt a hierarchy that prioritizes elimination over management:

1. Best: Eliminate Shared Secrets Entirely — Use cryptographic identity-based authentication (mTLS, workload identities, OIDC federation) that requires no shared secrets. This is the most secure approach because there are no credentials to steal or rotate manually. As discussed in the Favor Shared-Secret-Less Architectures section, eliminating shared secrets removes the management burden entirely, though private keys still exist and are handled by the platform.

2. Good: Centralize and Dynamically Generate — For secrets that cannot be eliminated, use centralized secrets management systems that generate credentials on-demand with short lifespans. Dynamic database credentials, temporary cloud access tokens, and just-in-time certificates minimize exposure windows.

3. Acceptable: Centralize and Rotate Regularly — When long-lived secrets are unavoidable (legacy systems, third-party integrations), store them centrally and rotate automatically. As covered in Automate Regular Key Rotation, systematic rotation limits the damage from compromised credentials.

4. Avoid: Static, Distributed Secrets — Hard-coded credentials, secrets in configuration files, and manually managed passwords represent the highest risk and should be eliminated through migration to higher tiers.

Favor Shared-Secret-Less Architectures [Shared-Secret-Less Design]

Modern security design favors eliminating shared secrets—the credentials that must be known to both sides of an interaction—rather than managing them. Long-lived API keys, passwords, and static credentials shared between caller and callee create operational overhead and expand the blast radius when compromised. Systems should instead prefer cryptographic identity-based authentication—mutual TLS with certificates, service meshes, or workload identity—where each side proves who it is with its own private key. Private keys still exist, but they are never shared: each side keeps its own, and the platform (service mesh, cloud KMS, workload identity system) handles generation, storage, and rotation. The label "secret-less" is a shorthand for "no application-managed shared secret"—not for "no cryptographic material anywhere."

Automate Regular Key Rotation [Key Rotation]

Some keys, such as database master keys, encryption keys for stored data, or cloud provider access keys (AWS Access Keys, Azure Service Principal keys), cannot be eliminated or made temporary. For these long-lived secrets, regular rotation is essential to maintaining security. Key rotation involves periodically updating these static keys to reduce the risk of unauthorized access, ensuring that even if a key is compromised, the potential damage is limited.

In critical systems, automation tools can manage key rotation seamlessly, minimizing human error and avoiding downtime. The rotation process must be designed for resilience: every step should be idempotent—safe to repeat without creating inconsistencies—and built to withstand unexpected interruptions. A proven approach is to maintain multiple active credentials with overlapping lifespans, allowing smooth failover during rotation. Applications must be designed to pick up new secrets at runtime without requiring redeployment, ensuring continuous operation while security evolves behind the scenes.

Regular rotation ensures that old keys are invalidated, preventing attackers from using compromised credentials for extended periods. This practice is especially important in cloud services, APIs, and infrastructure systems, where frequent access demands strict control.

Centralized Secrets Management Systems [Centralized Systems]

Centralized secrets management platforms provide a single source of truth for all credentials, eliminating secrets sprawl and enabling consistent security policies. Tools like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Secret Manager offer critical capabilities: encrypted storage with fine-grained access control, comprehensive audit logging of all secret access, automated rotation for supported services, versioning to track changes and enable rollback, and dynamic secrets generation that creates credentials on-demand.

By centralizing secrets, organizations gain visibility into what secrets exist, who accesses them, and when rotation is required. Access policies enforce least privilege, ensuring applications and users retrieve only the specific secrets they need. Centralization also enables consistent encryption, backup strategies, and compliance controls across all credentials.

Secrets Detection and Prevention [Secrets Detection]

Organizations must prevent secrets from entering insecure locations in the first place. Pre-commit hooks scan code for patterns matching API keys, passwords, or tokens before allowing commits. Secrets scanning tools analyze repositories, container images, and infrastructure code to detect accidentally committed credentials. When secrets are discovered, automated workflows immediately rotate the exposed credential, notify security teams, and block deployments.

Developer training emphasizes recognizing secrets and understanding proper handling procedures. Code review checklists explicitly verify that no hard-coded credentials exist. CI/CD pipelines fail builds that contain embedded secrets, preventing vulnerable artifacts from reaching production. This defense-in-depth approach catches secrets at multiple stages before they can cause harm.

Runtime Secrets Injection [Runtime Injection] {3}

Applications should never contain secrets at build time—credentials must be injected at runtime from centralized secret stores. This pattern ensures that container images, machine images, and deployment artifacts remain generic and can be safely stored in registries without containing sensitive data.

Runtime injection occurs through multiple mechanisms: environment variables populated from secrets managers at container startup, volume mounts using Kubernetes Secrets or CSI drivers that dynamically fetch credentials, sidecar containers that retrieve and refresh secrets transparently, and application libraries that directly integrate with secrets management APIs. The key principle is that applications request secrets when they start or when needed, rather than carrying them as embedded configuration.

This approach enables safe artifact reuse across environments, simplifies credential rotation without redeployment, and ensures that secrets never persist in version control or image registries.

Developer Experience and Workflow [Dev Workflow] {3}

Effective secrets management must balance security with developer productivity. Developers need access to credentials for local development and testing without compromising security or creating friction. Organizations should provide developers with personal, scoped credentials that grant access only to development resources, not production. Self-service portals enable developers to request temporary credentials that automatically expire, eliminating the need for shared passwords or service accounts.

Local development environments should mirror production patterns: applications fetch secrets from a development-tier secrets manager rather than from local .env files. Onboarding documentation clearly explains how to access secrets, and tooling abstracts complexity through CLI commands or IDE plugins. When developers can easily access the credentials they need through secure channels, they're less likely to work around security controls by hard-coding or sharing credentials.

Secrets in CI/CD Pipelines [CI/CD Secrets]

CI/CD pipelines require secrets to deploy applications, run tests against databases, and publish artifacts. These pipeline credentials represent high-value targets because they often have broad permissions. Organizations must treat pipeline secrets with the same rigor as production credentials.

Modern CI/CD platforms integrate with secrets managers, retrieving credentials dynamically at pipeline execution rather than storing them in pipeline configuration. Access is scoped to specific pipelines and jobs using workload identity or OIDC federation, eliminating the need for long-lived service account keys. Pipeline definitions never contain secrets—only references to secret names or paths. Comprehensive logging captures which pipelines accessed which secrets, providing audit trails for security investigations.

For maximum security, pipelines should use temporary, just-in-time credentials that exist only for the duration of the pipeline run and are automatically revoked upon completion.

Secrets Management Best Practices [Secrets Best Practices]

Beyond the hierarchy and tooling, organizations should follow fundamental secrets management principles. Never commit secrets to version control—use .gitignore and pre-commit hooks to prevent accidents. Rotate credentials regularly, especially after personnel changes or suspected compromise. Implement break-glass procedures for emergency access to critical secrets while maintaining audit trails. Use separate secrets for each environment to limit blast radius—development credentials should never work in production. Encrypt secrets at rest and in transit, even within internal systems. Finally, monitor for anomalous secret access patterns that may indicate compromised credentials or insider threats.

By adopting centralized secrets management, eliminating secrets where possible, and automating rotation and injection, organizations transform secrets from a liability into a controlled, manageable aspect of their security posture.

Production Operations Security [Production Security]

Production access is one of the highest-risk trust decisions in an organization. The system must decide when to trust a human with dangerous authority, for how long, through which controlled path, and with what audit trail. Every principle from the previous sections—verified identity, least privilege, time-bound access, separation of duties, traceability—converges here, applied to the most sensitive surface of the system.

Control Access to Production Operations [Prod Access] {1}

Access to production environments must be tightly controlled to prevent unauthorized changes and ensure system stability. Only essential personnel should have access, following the principle of least privilege. Implementing role-based access control (RBAC) helps assign specific roles and permissions, limiting actions based on job responsibilities. Additionally, enforcing multi-factor authentication (MFA) adds a layer of security.

Audit logs should track every access and action within production to ensure accountability and support incident investigation. Temporary access can be granted through just-in-time (JIT) access policies, revoking permissions automatically after a set period. Controlling access helps maintain operational integrity, reduces risks, and ensures compliance with security policies.

Secure Gateway Pattern [Secure Gateway]

In a Secure Gateway, users remotely connect to a server through a VNC or remote desktop interface to access a secured console where all production changes are executed. This setup ensures controlled access, allowing critical tasks to be performed efficiently while minimizing risks.

The system enforces best practices such as role-based access control (RBAC) and the principle of least privilege, ensuring users only have the permissions necessary for their tasks. Authentication is strengthened through MFA, YubiKey, and VPN access, ensuring only authorized personnel gain access.

Temporary permissions are granted on demand, and all actions performed within the console are comprehensively logged to maintain traceability and accountability. Sensitive operations, such as copy-paste actions, are actively monitored to reduce the risk of data leakage or accidental errors. This approach ensures operational security, balancing flexibility with robust safeguards to protect production environments from misuse and human error.

Safe Proxies Pattern [Safe Proxies] {3}

Another alternative is to use safe proxies as a control layer between users and production systems to limit direct access. Instead of granting unrestricted permissions, proxies allow only specific, pre-approved operations, ensuring that every action—whether routine or emergency—is logged and monitored. This approach minimizes the risk of mistakes, malicious activities, or unauthorized access.

By enforcing strict policies and permissions through safe proxies, organizations can secure production environments more effectively. This setup provides an additional layer of control and reliability without requiring significant changes to existing systems, ensuring both operational efficiency and security.

External Material

Google: Safe Proxies in Production Environments

AI Agent Security [AI Agents]

The rise of autonomous AI agents introduces a new class of actor inside our systems. Agents read data, call APIs, deploy code, and trigger workflows—often at machine speed and at scale. Traditional security models assume two categories of identity: humans and services. Agents fit neither cleanly: they act on behalf of users, but with autonomy; they execute code, but with non-deterministic reasoning. Securing them requires extending existing IAM principles to a new kind of identity, while addressing threats unique to LLM-driven systems.

Agents Are First-Class Identities [Agent Identity] {1}

An AI agent is not a feature of an application—it is an autonomous actor that takes actions in the system. !!Every agent must have its own identity, distinct from the user who invoked it and from the service that hosts it.!! Without a dedicated identity, agent actions blend into application logs, accountability disappears, and least-privilege becomes impossible to enforce. Treat each agent like a new employee: it gets a unique ID, a defined role, explicit permissions, and a complete audit trail.

Apply Least Privilege to Every Agent [Agent Least Privilege] {1}

The principle of least privilege applies to agents exactly as it applies to humans, but with even more discipline. !!An agent must receive only the permissions strictly required for its task—nothing more.!! A code-review agent reads pull requests; it does not need write access to production. A customer-support agent queries order history; it does not need access to payroll data. Granting broad permissions to an agent is far more dangerous than granting them to a human: the agent acts thousands of times faster, can be manipulated through prompt injection, and rarely questions an unusual instruction. The blast radius of an over-privileged agent is catastrophic.

Distinguish Agent Identity from User Identity [Agent vs User] {1}

When an agent acts on behalf of a user, two identities are involved: the agent itself and the user it represents. The system must track both. !!The effective permissions are the intersection—never the union—of what the agent is allowed to do and what the user is allowed to do.!! An agent acting for a junior employee must not be able to access resources that the junior employee cannot access directly. This dual-identity model prevents privilege escalation through the agent and ensures that user-level controls (data classification, regional access, separation of duties) continue to apply when the agent operates.

Prompt Injection Is the New Attack Vector [Prompt Injection] {1}

LLMs cannot reliably distinguish trusted instructions from untrusted data. Any content the agent reads—an email, a document, a webpage, a database row—can contain hidden instructions that hijack its behavior. !!Treat every input to an agent as potentially adversarial, exactly as you would treat user input in a web form.!! Do not rely on the model to refuse malicious instructions; rely on the surrounding system: scope its tools narrowly, validate every action against policy before execution, and require human approval for sensitive operations. The model is the attacker's surface; the guardrails are the defense.

Limit Agent Tools and Blast Radius [Agent Tooling]

An agent's power comes from the tools it can call. Each tool is a privilege; each privilege expands the blast radius of a compromised or manipulated agent. Curate the tool catalog deliberately: prefer narrowly-scoped, read-only tools over broad, write-capable ones; prefer tools that operate on a single record over tools that operate on ranges; prefer tools whose effects are reversible. Sensitive operations—deleting data, transferring funds, deploying to production, sending external communications—should require explicit human-in-the-loop approval, even when the agent is technically authorized to perform them.

Audit Every Agent Action [Agent Audit]

Agents act fast, often, and in ways that are hard to predict. A complete audit trail is the only way to detect misuse, debug failures, and satisfy compliance. !!Log every agent decision: the prompt it received, the tools it considered, the tool it called, the inputs and outputs, and the user on whose behalf it acted.!! Because agents reason probabilistically, the same input can produce different outputs across runs—making detailed traces essential for post-incident analysis. Treat agent audit logs as security-critical telemetry, with retention and access controls aligned to your most sensitive systems.

Time-Bound Agent Sessions [Agent Ephemerality]

The principles of ephemeral access and short-lived credentials apply to agents with even greater urgency. A long-lived agent session accumulates context, drifts from its original task, and becomes a high-value target. Sessions should be scoped to a single task, expire quickly, and be re-authenticated before any sensitive operation. Credentials issued to agents must be short-lived tokens—never static API keys—and ideally bound to the specific tools and resources required by the current task. When the task ends, the credentials and the context die with it.

To Delete [To Delete]

[REMOVED SLIDE — Four Anchors] The Four Anchors of Modern Trust [OLD Four Anchors]

This chapter is organized around four anchors that together replace the perimeter as the foundation of trust. !!Identity — every actor is verifiable through cryptographic proof, not passwords or network location. Authorization — every permission is explicit, scoped to the minimum needed, and evaluated per request. Time — access is short-lived, expiring by default, renewed only when re-justified. Audit — every action is traceable, so trust decisions can be reviewed, challenged, and improved.!! Every section that follows—IAM, cloud identity, secrets, production access, Zero Trust, AI agents—expresses these same four anchors in a different context.

[REMOVED SLIDE — Zero Trust monolith] The "Don't Trust Anyone" Principle [OLD Don't Trust Anyone]

The traditional approach to cybersecurity relied on a trust perimeter, where everything inside the network was trusted, and everything outside was not. The diagram below illustrates a traditional Corporate Perimeter. The diagonal lines represent the untrusted zone, indicating potential threats. The white background area represents the trusted perimeter. Once inside this zone, there is complete trust among systems/users. If an intruder manages to penetrate this zone, all internal resources become accessible from a network perspective

However, as organizations move to the cloud and adopt distributed architectures, the concept of a single, well-defined perimeter becomes obsolete. Modern systems span multiple environments—on-premises, cloud, and hybrid—making it impractical and ineffective to rely solely on perimeter-based security. Attempting to extend the traditional perimeter across such diverse systems would not only be complex but also create gaps in security and reduce operational efficiency.

In response to these challenges, the Zero Trust model has emerged as a modern approach to security. Zero Trust (or 'Don't Trust Anyone') assumes that no entity—whether inside or outside the network—should be implicitly trusted. Every resource, including users, services, networks, databases, and containers, is assigned a unique digital identity. Access is granted only after verification through mutual authentication and a policy check. With this approach, security is continuously enforced, ensuring strict access control at every point of interaction. The shift from a trust perimeter to Zero Trust provides greater resilience in today's interconnected digital landscape.

One possible way to implement Zero Trust is by using a Public Key Infrastructure (PKI) provider to manage digital identities and secure mutual Transport Layer Security (mTLS) connections for resource communication. The PKI provider issues certificates to each legitimate resource, ensuring they have a verified and unique identity. Resources communicate over secure mTLS connections, which authenticate both parties and encrypt transmitted data. Access requests between resources are governed by strict policies defined in a policy enforcement proxy or gateway, which checks these policies to determine if access should be allowed or denied.

[REMOVED IMAGE] OIDC 6-step redirect flow

[REMOVED SLIDE] IAM: Direct vs Federated Authentication [IAM: Authentication]

IAM services support two fundamental approaches to authentication. Direct Authentication: Users or services prove their identity directly to the IAM system using credentials—passwords, certificates, hardware-backed keys, biometric data, or short-lived tokens. Each offers different security levels and convenience, but the principle remains the same: presenting proof of identity directly to the system for validation. Federated Authentication: IAM delegates authentication to external trusted identity providers. Users authenticate with an external system (corporate directory, social provider), and IAM trusts that system's decision.

[REMOVED SECTION] Building a Hybrid Identity Architecture [Hybrid IAM]

The Challenge: Multiple Trust Domains [The Challenge]

We've covered the standard identity protocols (OAuth, OIDC, SAML, mTLS, SPIFFE) and how cloud providers implement IAM. Now we bring these together to address a fundamental challenge: modern architectures rarely exist within a single trust boundary.

Services communicate across clouds, external systems need access to internal resources, internal services call external APIs, and microservices authenticate each other within orchestration platforms like Kubernetes. Each of these scenarios involves different trust domains—systems that don't inherently recognize each other's identities.

The standard protocols provide the mechanisms to bridge these boundaries. Depending on the scenario, these protocols may extend cloud IAM, replace it entirely, or bridge between disparate systems.

Scenario Overview [Overview]

Source	Destination	Mechanism	Relationship to Cloud IAM
External service (GitHub Actions, CI/CD)	Cloud resources	OIDC federation → IAM role	Extends cloud IAM
Your cloud service	External API (Stripe, Salesforce)	OAuth Client Credentials	Independent of cloud IAM
External users (via corporate IdP)	Cloud resources	OIDC/SAML federation	Extends cloud IAM
Internal service (K8s pod)	Internal service (K8s pod)	mTLS, Service Mesh, SPIFFE	Replaces cloud IAM
AWS service	Azure/GCP resource	Cross-cloud workload identity	Bridges cloud IAMs
Partner organization users	Your resources	B2B SAML/OIDC federation	Extends cloud IAM

Scenario 1: External Services Accessing Cloud Resources [Inbound Services]

Systems like GitHub Actions, GitLab CI, or third-party services running outside the cloud have no native cloud identity. These external services need to perform operations on cloud resources—deploying infrastructure, pushing to container registries, or accessing secrets.

Standard protocols (primarily OIDC) enable these services to authenticate, establish trust with the cloud provider, and assume IAM roles to perform operations. The external service presents a signed token from its identity provider, the cloud validates this token against a pre-configured trust relationship, and grants temporary credentials with specific permissions.

This approach eliminates the need for long-lived API keys or service account credentials stored in CI/CD systems—a significant security improvement over traditional approaches.

Scenario 2: Your Services Calling External APIs [Outbound APIs]

When your cloud-native services need to call external third-party APIs (Stripe for payments, Twilio for messaging, Salesforce for CRM), the authentication flow is reversed. Your service must authenticate to the external system using that system's required mechanism.

Common approaches include:

• OAuth 2.0 Client Credentials Flow: Your service authenticates with the external API's authorization server using client credentials and receives an access token for API calls.

• API Keys: Many external services still require API keys, which must be securely stored and rotated in your secrets management system.

• mTLS: Some high-security external APIs require mutual TLS for service authentication.

This scenario operates independently of cloud IAM—the external service doesn't know or care about your cloud identity. Your responsibility is secure credential management for these outbound connections.

Scenario 3: External Users via Federated Authentication [User Federation]

Users authenticate through external identity providers (Google, Okta, Microsoft, corporate Active Directory) rather than maintaining separate credentials for each cloud platform. Through protocols like OIDC or SAML, these users access cloud resources by federating their existing identities and assuming appropriate IAM roles.

This scenario is the foundation of enterprise single sign-on (SSO). Users log in once to their corporate identity provider and gain access to cloud consoles, applications, and resources across multiple platforms without additional credentials.

Scenario 4: Internal Service-to-Service Communication [Platform Identity]

When two services communicate within the same platform—such as two pods in a Kubernetes cluster—cloud IAM is typically not involved. These services operate within a different trust domain managed by the orchestration platform itself.

Internal service-to-service authentication commonly uses:

• Service Mesh with mTLS: Platforms like Istio, Linkerd, or Consul automatically issue certificates to each service, establish mTLS connections, and enforce authorization policies. The mesh handles certificate rotation, identity verification, and policy enforcement transparently.

• Kubernetes Service Accounts: Native Kubernetes identity mechanism that provides tokens to pods, enabling RBAC-based authorization for API access and inter-service communication.

• SPIFFE/SPIRE: For organizations requiring platform-agnostic workload identity, SPIFFE provides a consistent identity framework across Kubernetes, VMs, and multi-cloud environments.

This scenario replaces cloud IAM rather than extending it—the identity and access controls operate entirely within the platform layer.

Scenario 5: Multi-Cloud Identity [Multi-Cloud]

Organizations operating across multiple cloud providers face the challenge of services in one cloud needing to access resources in another. AWS services calling Azure APIs, GCP workloads accessing AWS S3, or hybrid on-premises services connecting to multiple clouds all require cross-cloud identity solutions.

Modern approaches include:

• Workload Identity Federation: Cloud providers increasingly support federating identities from other clouds. For example, AWS workloads can assume Azure roles using OIDC tokens, and GCP workloads can access AWS resources through workload identity pools.

• SPIFFE/SPIRE: Provides a cloud-agnostic identity layer that works consistently across all environments, issuing verifiable identities regardless of where workloads run.

• Centralized Identity Broker: Some organizations deploy a central identity service that issues tokens accepted by all their cloud environments.

This scenario bridges different cloud IAMs using standard protocols as the common language.

Scenario 6: B2B Partner Federation [B2B Federation]

When partner organizations' employees need controlled access to your resources, B2B federation establishes trust between your identity system and theirs. Rather than creating accounts for external users in your system, you trust their corporate identity provider to authenticate them.

SAML remains prevalent for B2B federation due to its maturity and widespread enterprise adoption, though OIDC is increasingly used for newer integrations. The key difference from Scenario 3 (User Federation) is the organizational boundary—you're establishing trust with another company's identity infrastructure, not just integrating with consumer identity providers.

Choosing the Right Approach [Decision Guide]

When designing identity solutions across trust boundaries, consider:

1. Who controls the identity? If you control both sides, you have more flexibility. If external parties control identity, you must adapt to their supported protocols.

2. What's the trust relationship? Federation extends trust, mTLS establishes mutual trust, and API keys represent one-way trust.

3. Is cloud IAM involved? Internal platform communication often bypasses cloud IAM entirely. External access typically extends cloud IAM.

4. What's the credential lifecycle? Prefer short-lived, automatically rotated credentials. Avoid long-lived secrets wherever possible.

5. What's the platform? Kubernetes-native solutions differ from cross-cloud or hybrid scenarios. Choose protocols that match your infrastructure.