Design for Trust

Chapter Info

Calculating... Writing Progress: 80%

Trust is the confidence that a request is legitimate. A system trusts a request only when it can verify who is making it, what that identity is allowed to do, and whether those assertions are still valid. !!Modern systems no longer derive that confidence from network location or shared secrets.!! Instead, trust must be established explicitly, verified cryptographically when possible, limited in scope and time, and re-evaluated continuously.

This chapter explains how modern systems build that trust: through authentication, authorization, cryptographic identity, cloud IAM, open identity protocols, secrets management, and ultimately Zero Trust.

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 assumed to be legitimate. Passwords, network addresses, and being "behind the firewall" served as sufficient proof of trust—a model that 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.

Introducing Zero Trust [Zero Trust] {1}

Zero Trust is the architectural response to this new reality. !!It is not a new authentication mechanism or protocol, but an architecture built from the mechanisms introduced throughout this chapter: identity, authentication, authorization, cryptographic proof, short-lived credentials, and continuous verification.!! The following sections explain those mechanisms first; the final Zero Trust section shows how they fit together.

Identity and Access Management (IAM) [IAM] {1}

Many of the mechanisms in this chapter belong to one broad discipline: Identity and Access Management (IAM). !!IAM manages identities and controls their access to systems.!! It authenticates principals, authorizes their actions, and manages the credentials, roles, and policies that support those decisions. Whether the principal is a human, a service, a workload, or an AI agent, IAM provides the foundation for deciding who can do what.

Principles for Designing Trust [Trust Design Principles]

Trust should never be granted broadly, implicitly, or indefinitely. Long-established security principles provide the foundation for every mechanism in this chapter: !!grant only the access required, deny everything that has not been explicitly allowed, limit access in time, and make every action attributable.!! These principles predate Zero Trust and guide every trust mechanism introduced in this chapter. Before the mechanisms themselves, we state the rules those mechanisms must respect.

Least Privilege [Least Privilege] {1}

The Principle of Least Privilege (PoLP) grants users, applications, and systems the minimum levels of access needed to perform their tasks—so the potential damage from an accident or security breach stays bounded. It is common sense: when giving your car to a mechanic, you remove unnecessary keys from the keychain—no need to include your house keys.

Least Privilege in Practice [Least Privilege in Practice] {1}

Applying least privilege means creating highly specific roles and permissions tailored to exact needs. For users, roles like "read-only", "support", "admin", "developer"—each with only the permissions required for that function. For services, each receives only the specific permissions needed for its operations. !!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.!!

Perform Sensitive Operations in Trusted Environments [Trusted Environments]

Not every operation should be performed where it originates. When an operation involves sensitive data, privileged credentials, security decisions, or trusted identities, prefer executing it inside a trusted backend rather than in client-side code. A trusted backend can authenticate itself, enforce policy, protect sensitive material, and keep security-critical logic under your control. Let the client interact with the user; let trusted systems perform sensitive work.

Everything Is Forbidden by Default [Default Deny] {1}

The simplest way to enforce least privilege is to make everything forbidden by default. Every capability the system offers must be explicitly granted; anything not granted is denied. This forces every permission to be intentional and named—no permission exists by accident, no permission survives when the rule that granted it is removed. !!Deny is the baseline; every allow is a deliberate exception.!!

When Identity Can't Be Verified, Deny [Fail Secure] {1}

Default deny is not only about the absence of a rule; it is also about the failure of a verification. When identity or authorization cannot be established—an unreachable IdP, a policy service timeout, an expired key, a malformed token, a signature that fails to verify—the system must refuse the request. !!A verification failure must never silently become permission—uncertainty means deny, not allow.!!

Time-Bound Credentials [Ephemeral Credentials] {1}

!!No credential is issued without an expiry.!! Certificates, tokens, and keys all carry a lifetime bounded by the task they support—minutes for a request, hours for a session, days at most for anything reused. Machine credentials issued by cloud STS, workload identity, or a certificate authority are short by design and renewed automatically when the workload still needs them. When the lifetime ends, the credential stops being valid without anyone having to remember to revoke it—so the compromise of a leaked credential is bounded by its remaining seconds, not by how long the account exists.

External Material

AWS:SEC02-BP02 Use temporary credentials

Separation of Duties [Separation of Duties] {1}

Some actions are too sensitive to be controlled by a single identity. !!Separation of duties divides a critical workflow across independent roles—one person requests access, another approves it; one system prepares a release, another authorizes its production deployment.!! The principle applies wherever a single actor could cause disproportionate damage: payments, key rotation, admin changes, deploys. Compromising one identity should not be enough to complete the entire operation.

Traceability [Traceability] {1}

Least privilege, default deny, and time-bound access limit what can be done and for how long. Traceability closes the loop by making every action attributable. !!Each request must be linked to the authenticated principal that performed it—human, service, workload, or AI agent—never to an IP address or a shared account.!! This is what makes the other principles enforceable: without reliable attribution, they restrict behavior but cannot explain what happened.

Authentication [Authentication]

Authentication establishes who is making a request by verifying evidence of a claimed identity. It is one of the core responsibilities implemented by Identity and Access Management systems, but the concept extends beyond any specific IAM platform or protocol. This section covers authentication as a lifecycle: actors and their identities, the evidence used to prove them, the assurance that evidence carries, the sessions that extend authentication forward in time, the step-up challenges that reassess it, and the architectural decision to delegate authentication to a trusted third party. The next section then shows how the result of that authentication is turned into a verifiable identity that can travel across systems.

Every Actor Has an Identity — Human, Machine, AI Agent [Every Actor] {1}

Before authentication can prove anything, every actor must have an identity to prove. !!Every independently accountable actor—human, service, pod, node, AI agent—must have a distinct identity, and credentials should never be shared across unrelated actors.!! 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 be identifiable in exactly the same way. Shared accounts and shared credentials collapse least privilege, revocation, and traceability into a single anonymous line. Identities are provisioned upstream; authentication verifies control of that identity, and the next slides describe how.

Authentication Evidence [Authentication Evidence] {1}

Once an actor has an identity, authentication is the act of proving that the caller is who they claim to be. That proof always rests on evidence the caller can present and the system can check. !!Evidence takes many forms: something the caller knows (a password), something they have (a private key, a smart card, a hardware token), something they are (a biometric factor), or something the platform can attest about the actor.!! Multi-factor authentication combines several categories at once, so that compromising a single credential is not enough to impersonate the identity. What matters conceptually is not the specific mechanism but the shape: an actor presents evidence, the system verifies it, and only then does the identity count as authenticated.

Authentication Strength Must Match the Risk [Strength to Risk] {1}

Authentication is not binary—it produces a level of assurance. A password gives modest assurance; adding a one-time code gives more; a passkey bound to a hardware-protected key gives more still. !!The strength of authentication should match the risk of the requested action, not the maximum available for every request.!! Requiring the strongest proof everywhere does not make the system safer—excessive friction encourages insecure workarounds and blurs the line between routine access and genuinely sensitive operations.

You Can't Reauthenticate Every Request [Session] {1}

Repeating authentication on every request would be impractical—users cannot enter a password, tap a passkey, or renegotiate mTLS for each call. !!After a successful authentication, the system issues a session—a cookie, a token, sometimes a certificate—that stands in for the authentication on subsequent requests.!! The session becomes the credential presented from that point on, which means a strong login followed by an unbounded or stealable session is still weak authentication. Sessions must therefore be short-lived, revocable, and protected against theft—when a session outlives the conditions that justified it, its continued validity no longer represents current trust.

Some Actions Require Stronger Proof [Step-Up AuthN] {1}

A session is enough for everyday actions, but not for sensitive ones. A hijacked session alone should not be enough to perform the operations that cause the most damage. Changing an account password, enrolling a new passkey, approving a payment, or accessing production may require a fresh, stronger proof. !!Step-up authentication asks for stronger proof only when the risk increases.!!

Applications Can Authenticate Users Directly [Direct Authentication] {1}

The simplest authentication model is for an application to authenticate its own users. !!The application stores or verifies credentials, applies MFA when needed, creates the session, and decides whether authentication succeeds.!! This model is reasonable for a single isolated application with its own user base. It becomes difficult to sustain as soon as several applications need to authenticate the same users: credential storage, MFA, password recovery, revocation, security policy, and audit are then implemented—and secured—separately in every application, and users end up with one login per system.

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

!!Federation centralizes authentication in a trusted Identity Provider (IdP) that authenticates the caller once and vouches for that identity to any downstream system that trusts the same provider.!! Downstream applications do not repeat the authentication—they trust the IdP to establish the identity, and independently verify the evidence it issues. A single IdP can serve many applications, so security policy, revocation, and audit are defined and secured in one place.

User-Centric Federation Uses Browser Redirects [Browser Mediates] {1}

When federation is used to authenticate a human user, the browser participates in the authentication flow. The application uses standard HTTP redirects to send the browser to a trusted Identity Provider. After authenticating the user, the Identity Provider redirects the browser back to the application with an authentication response. !!Redirects let the application delegate user authentication without receiving or handling the user's credentials.!!

Verifiable Identity [Verifiable Identity]

An authenticated identity is only useful if it can travel from one system to another without being re-authenticated at every hop. This section explains how modern systems turn identity into something portable and independently verifiable—proven cryptographically, bound to an authority, anchored in a root of trust, expressed as signed claims, and verified independently by each receiver. The rest of the chapter—cloud IAM, open identity protocols, machine authentication, secrets, and Zero Trust—all build on this layer.

Asymmetric Cryptography Enables Verifiable Proof [Asymmetric Crypto] {1}

Proving identity across the network required a technology that did not exist for most of computing history. !!Asymmetric cryptography—a keypair where one key creates a proof while the other verifies it—made it possible to authenticate without sharing a secret.!! An actor can sign a request, and any verifier holding the corresponding public key can check that signature—but the signature alone proves only control of the private key, not the identity of its owner. That binding comes next. Every mechanism in the rest of this chapter—signed tokens, mTLS, SPIFFE, passkeys, workload identity—rests on that single invention.

Binding Cryptographic Proof to Identity [Bind Proof to Identity]

Verifying a signature only proves control of a private key—it does not tell us whose key it is. A trusted authority binds the public key to an identity: through a signed certificate, a public key registered against an account, an authenticator enrolled at an IdP, or a workload identity issued by the platform. Others can then verify both the signature and the identity it represents. !!Cryptography proves control of a key; a trusted authority binds that key to an identity.!!

Every Chain Ends at a Root of Trust [Root of Trust]

A trusted authority binds a public key to an identity—but why should that authority itself be trusted? Every verification chain eventually reaches a root of trust: something whose legitimacy is not established by another signature, but through a separate trusted process. A root certificate may be pre-installed in an operating system, a hardware identity may be provisioned into a TPM, or a root key may be securely generated and protected inside an HSM.

!!Cryptography does not create trust; it extends trust from an established root—every downstream verification is only as strong as the root it ultimately depends on.!!

Signed Claims [Signed Claims]

Once an identity has been authenticated, a trusted issuer expresses the result as a set of claims—short statements the issuer asserts about the authenticated identity and its context: "Alice, engineering, authenticated at 10:42, expires in one hour", or for a workload, "checkout-service, us-east-1, issued by the workload platform". The issuer signs those claims with its private key, so any receiver can verify who issued them and detect tampering. The claims themselves remain readable—their trust comes from the signature, not from secrecy. !!Signed claims are a portable, verifiable representation of what a trusted issuer asserts about an identity.!!

Signed Claims Travel with Every Request [Carrying Identity] {1}

Once claims have been signed, they can accompany subsequent requests in a token. Each request carries the identity information and context the receiver needs to make its decision, without having to look them up elsewhere. !!The token carries signed claims with the requests that depend on them.!!

Signed Claims Enable Independent Verification [Independent Verification]

With opaque credentials, a receiver may need to contact the issuer or consult shared state to determine what the credential represents and whether it is still valid. Signed claims can carry that information directly: the issuer signs once, and each receiver verifies the signature locally using the issuer's public key. !!Signature verification enables local verification without a per-request authentication callback.!!

Authorization [Authorization]

Authorization determines what an authenticated identity is allowed to do. It evaluates the principal, requested action, target resource, and current conditions against policy. Like authentication, it is a general security responsibility that IAM systems help implement consistently across users, workloads, and resources.

Policies [Policies] {1}

A policy is an explicit rule that defines who may perform which actions on which resources, under which conditions. Rather than scattering authorization decisions throughout application code, modern systems express them as declarative policies that can be reviewed, versioned, audited, and enforced consistently. A policy may grant a service permission to publish messages to a queue, allow a developer to deploy only to a staging environment, or permit an administrator to access production only during an approved maintenance window. !!Authorization belongs in policy, not in application code.!!

Principals, Actions and Resources [Principals & Resources] {1}

Every authorization decision evaluates the same fundamental elements: who is making the request, what they want to do, and what they want to do it to. The principal is the actor requesting access—a human, service, workload, device, or AI agent. The action is the requested operation, such as read, write, delete, invoke, or assumeRole. The resource is the object being accessed: a file, bucket, database, API, secret, or cloud service. Conditions such as time, network, device posture, or location may further influence the decision. !!Authorization always evaluates a principal performing an action on a resource.!!

Roles [Roles] {1}

Assigning permissions directly to every identity quickly becomes impossible to manage. Instead, systems group permissions into roles, which principals can be assigned or temporarily assume. A role represents a responsibility rather than an individual. Examples include reader, support-engineer, deployment-service, or database-admin. Multiple principals may assume the same role, while a single principal may assume different roles depending on the task being performed. !!Roles separate who someone is from what they are allowed to do.!!

RBAC — Role-Based Access Control [RBAC] {1}

Role-Based Access Control (RBAC) grants permissions through predefined roles rather than directly to users or services. A principal first receives one or more roles, and those roles determine the operations it may perform. RBAC is simple, predictable, and easy to audit, which explains why it is the dominant authorization model in enterprise systems. Its main limitation is flexibility: as organizations grow, roles often multiply or become overly broad to accommodate exceptions. !!RBAC assigns permissions through responsibilities, not individuals.!!

ABAC — Attribute-Based Access Control [ABAC] {1}

Attribute-Based Access Control (ABAC) evaluates policies using attributes available at the time of the request rather than relying solely on fixed role membership. Policies can consider attributes of the principal (department, clearance), the resource (classification, owner), the environment (time of day, network, device), and even the requested action itself. This makes ABAC significantly more flexible than RBAC and particularly well suited to large, dynamic environments. Rather than asking "Does Alice have the Administrator role?", ABAC asks "Does the current request satisfy the policy?" !!RBAC grants permissions through predefined roles; ABAC computes permissions from the current context.!!

Authorization Can Be Requested [Authorization Requests] {1}

Authorization is not always assigned in advance. An application may request permission to perform a specific operation when it is needed. The authorization authority evaluates that request and grants only the access permitted by policy, administrative approval, user consent, or other authorization rules. !!The requester describes the access it needs; the authorization authority decides what is granted.!!

Separate Policy from Enforcement [Policy vs Enforcement]

Authorization has two distinct responsibilities: deciding whether an action should be allowed, and enforcing that decision. !!Keeping them separate does not mean calling a central service on every request!!—policies can be authored centrally, distributed to many enforcement points, cached locally, or embedded in service meshes and API gateways. What matters is not where the decision runs, but that policy remains independent from the component enforcing it—so rules can change without redesigning every application.

Putting Identity and Authorization Together [Putting It Together] {1}

!!Authentication establishes identity; authorization evaluates what that identity may do.!! Together they form the two responsibilities of IAM. Modern systems implement them through a small set of mechanisms introduced in the previous sections: verifiable identity, evidence the receiver can check, federation, and authorization policy. !!The next section shows how cloud platforms turn these concepts into a unified IAM control plane.!!

Identity as Platform Infrastructure [Platform Identity]

The previous sections described IAM independently of any vendor. Modern cloud providers package those same concepts into integrated IAM platforms—the concrete environment where most modern systems actually run. Every major cloud implements the same identity and access management model, with different APIs but the same primitives. Every user and workload becomes a principal, and every resource receives a canonical identifier that policies can reference—so a single set of rules governs access across compute, storage, networking, and every other cloud service.

IAM Services [IAM Services] {1}

Each major cloud provider packages identity and access management into a single, centralized service: AWS IAM, Azure Entra ID, and Google Cloud IAM. Inside the cloud, identities are already established and managed by the platform—the primary task of IAM is therefore authorization: defining which principals may perform which actions on which resources. !!IAM acts as the control plane that defines principals, roles, and policies across users, workloads, and infrastructure!!—so every access request, whether a user opens the console, a service calls an API, or an application reads from storage, is evaluated against the same authorization model.

Identity Becomes Infrastructure [Identity as Infrastructure] {1}

!!Cloud platforms make authentication an infrastructure concern.!! Every workload receives a managed identity, and the platform automatically proves that identity on every request. When a Lambda calls S3, or a VM calls another service, the platform attaches the identity and signs the request using credentials it manages—the application never stores credentials, never signs anything, never implements authentication itself. Every request therefore carries a verifiable identity that authorization and auditing can rely on—and the same idea reappears later in the chapter with Kubernetes workload identity, SPIFFE, and mTLS: authentication moves out of application code and into the platform itself.

Cloud Platforms Give Every Principal and Resource a Canonical Name [Canonical Names] {1}

Cloud platforms make the abstract authorization model concrete by assigning canonical identifiers to every principal and resource. !!Every Lambda, EC2 instance, service account, bucket, database, secret, and queue receives a globally unique name that policies can reference directly!!—so the same authorization rules described in the abstract can be written, deployed, and audited at scale without any custom naming layer in between.

Naming Conventions Across Clouds [Naming Conventions] {2}

Each cloud provider expresses these canonical identifiers in its own format. The names differ; the principle does not—every principal and every resource is addressable by a single global identifier.

IAM: Authentication Recommendations [AuthN Recommendations]

Whether identity is issued by cloud IAM or a standard protocol, how identities are proven reduces to three rules. !!For humans, use federated identity!!—delegate authentication to a single Identity Provider; never let applications manage passwords themselves. !!For workloads, use workload identity!!—services prove themselves cryptographically with credentials the platform issues, not with shared secrets. !!Avoid application-managed credentials!!—API keys, static tokens, and shared passwords in configuration are exactly the long-lived secrets modern IAM is designed to eliminate.

Open Protocols for Human Identity [Human Protocols]

Open protocols let applications establish and use human identity without relying on reusable shared secrets such as passwords. Some delegate authentication to a trusted Identity Provider; others replace passwords with cryptographic proof. !!Open protocols separate identity, cryptographic proof, and session while keeping reusable credentials out of applications.!!

OIDC and SAML: Protocols for Federated Login [OIDC & SAML]

OIDC and SAML are two standard protocols that let an application authenticate users through a trusted Identity Provider. Instead of collecting credentials itself, the application redirects the user to the IdP, which authenticates the user and redirects back with a signed response confirming their identity—the familiar "Sign in with Google" experience, whether the provider is Google, Microsoft, Apple, or a corporate IdP. After validating the response, the application typically creates its own local session for the user, separate from the session maintained by the Identity Provider. !!OIDC is the modern, JSON-based choice for web, mobile, and cloud-native apps; SAML is the XML-based standard still dominant in enterprise SSO and B2B.!!

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

Single Sign-On uses the same federated login flow described in the previous slide. The difference is that multiple applications can reuse the same session established with the Identity Provider. As long as that IdP session remains valid, the user can access any of those applications without authenticating again. The IdP sends a separate authentication response to each application, and each application creates its own local session. !!One IdP session enables multiple independent application sessions.!!

WebAuthn/Passkeys: User Authentication Without Passwords [WebAuthn]

Most Identity Providers still authenticate users with passwords, often combined with MFA. WebAuthn—and passkeys built on it—replace the shared password with proof of possession. A device such as a phone, laptop, or security key holds a private key and signs a fresh random number sent by the site, which the site verifies with the public key. !!The private key never leaves the device.!!

Open Protocols for Delegated Authorization [Delegated Authorization]

Authentication answers who is the user? Delegated authorization answers a different question: what may another application do on that user's behalf? Rather than sharing passwords with every application that needs access to your data, you grant each application a limited, revocable authorization to act for you. !!Delegated authorization keeps credentials with the service that authenticates the user and gives applications only the scoped, time-limited access they actually need.!!

OAuth: Delegated Access to Your Data [OAuth] {1}

OAuth lets an application access resources managed by another service without receiving the user's password—for example, a photo-printing service accessing photos stored in the cloud. The metaphor is a valet key: a limited key that lets the valet drive your car but not open the trunk. You authenticate directly with the service holding your data and approve specific permissions; the requesting app receives a time-limited, revocable access token—never your password. !!OAuth delegates access; OIDC adds an identity layer on top of the OAuth 2.0 framework.!!

Proof of Possession for OAuth Tokens [DPoP] {1}

OAuth access tokens are commonly bearer tokens: whoever obtains the token can use it until it expires—a stolen access token can be replayed directly against the resource server. Short lifetimes limit the damage, but do not eliminate it. Proof-of-possession mechanisms such as DPoP bind the token to a cryptographic key generated and held by the client instance that obtained it. For each request, that client instance must produce a new signed proof demonstrating control of the corresponding private key. A stolen token alone is therefore not enough. !!The same proof-of-possession principle used by WebAuthn to authenticate a user is applied here to protect the use of an OAuth access token.!!

Open Protocols for Workload Identity [Workload Protocols]

Every distributed system is full of workloads communicating with other workloads. Unlike humans, workloads cannot open a browser or complete an interactive login: they must authenticate automatically on every call. Some present shared credentials such as API keys, passwords, or bearer tokens; others prove their identity using certificates, signed requests, or federated tokens. !!Workload identity is the set of mechanisms that let software establish and prove its identity without a human in the loop.!!

Shared-Secret Authentication [Shared Secret]

Many workload-to-workload interactions authenticate by presenting a reusable credential, such as an API key, service password, or bearer token. The receiving system verifies that the caller possesses a valid credential. !!Simple and still widespread, this model requires credentials to be securely issued, distributed, stored, rotated, and revoked—every additional copy or storage location creates another place where a credential can leak.!!

mTLS: Mutual Authentication Without Sharing Secrets [mTLS]

Standard TLS authenticates only the server: the client verifies who it is talking to, but the server has no cryptographic proof of the caller at the transport layer. Mutual TLS extends the handshake so both peers present certificates and prove control of their corresponding private keys before any application data is exchanged. A trusted Certificate Authority signs each certificate, binding a workload identity to its public key. Because both peers trust that authority, they can authenticate each other during the handshake and establish a shared symmetric session key. All subsequent application traffic is then protected through that authenticated TLS connection, without API keys or bearer tokens in request headers

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

mTLS defines how workloads authenticate with certificates. SPIFFE defines a standard identity format for those certificates and how they are issued, rotated, and managed. Every workload receives a portable cryptographic identity that can be verified consistently across Kubernetes, virtual machines, on-premises systems, and multiple clouds. Authentication and authorization policies can therefore follow the workload rather than its network location. SPIFFE standardizes workload identity; mTLS turns that identity into mutual authentication.

Cross-Cloud Workload Identity Federation [Cross-Cloud Federation] {2}

SPIFFE federation extends workload identity beyond a single trust domain. Each domain keeps its own Certificate Authority and issues its own SPIFFE identities, but the domains exchange trust bundles so that certificates issued by one domain can be validated by the other. Workloads can therefore authenticate across trust domains using the same mTLS mechanism, without sharing long-lived credentials.

External Workload Role Assumption [Role Assumption]

A workload running outside a cloud can assume a role inside that cloud to access its resources. The cloud is configured to trust an external OIDC issuer, and the workload presents a signed token issued by it. The cloud verifies the token against the role’s trust policy and, if the conditions are satisfied, issues short-lived credentials for that role. No long-lived cloud credentials need to be stored or distributed

Rethinking Secrets [Rethinking Secrets]

The previous sections introduced many ways to prove an identity: passwords, API keys, certificates, signed tokens, workload identities, mTLS, WebAuthn. Some of them—asymmetric cryptography, certificates, signed tokens, mTLS, workload identity, OIDC federation—replace something a caller must hold and reveal with something a caller can prove without exposing. Others—passwords, API keys, shared credentials—remain in the "hold and reveal" category. !!This last section on identity mechanisms names that shift explicitly: shared secrets become the exception, not the rule—and when they cannot be eliminated, they must be managed as a controlled, contained liability.!!

Confidentiality vs Legitimacy [Two Problems] {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 [Hiding Data]

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: Authenticity and Integrity [Proving Origin]

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—and what must remain protected is not the message, but the private key that creates the proof.

The Wax Seal: An Analog Answer [Wax Seal]

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 did not survive into the modern era.

Legitimacy Treated as Confidentiality [Locked Message]

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.!! 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 Bootstrap Problem [Bootstrap]

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.

Secrets Do Not Scale [Don't Scale]

Beyond the bootstrap problem, 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 [New Paradigm] {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 by Proof, Confidentiality by TLS [Split Concerns] {1}

Once legitimacy is decoupled from secrecy, the two concerns separate cleanly. !!Identity is proven by a signature the receiver can verify independently; confidentiality is provided by TLS wrapping the request in transit.!! Neither depends on the other, and neither depends on a secret the two sides had to share in advance. The application no longer proves legitimacy by revealing a reusable credential—the platform establishes the caller's identity and signs or attests the request. Shared secrets remain necessary for confidentiality in some contexts, but they are no longer the foundation of trust.

Managing the Secrets That Remain [Managing Remaining Secrets]

Shared secrets are no longer the foundation of trust—but they have not disappeared. Legacy systems, third-party services, CI/CD pipelines, and encryption at rest still depend on them. !!For the ones that remain, the goal shifts from avoiding secrets to containing them!!: minimize sprawl, centralize storage, prefer dynamic generation over static values, rotate what cannot be short-lived, inject at runtime, and detect leaks early. This section is the playbook for that containment.

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!!—every level up removes an entire class of operational risk.

1. Best: Eliminate Shared Secrets Entirely — Use cryptographic identity-based authentication (mTLS, workload identities, OIDC federation), where each side proves itself with its own private key rather than exchanging a shared credential. 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. "Secret-less" is shorthand for no application-managed shared secret—not for no cryptographic material anywhere.

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, database master keys, cloud access keys), store them centrally and rotate automatically. Rotation must be designed for resilience: idempotent steps, overlapping credential lifetimes for smooth failover, and applications capable of picking up new secrets at runtime without redeployment.

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.

Centralized Secrets Management Systems [Centralized Systems]

Centralized secrets management platforms—HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager—provide a single source of truth for all credentials, eliminating sprawl. They offer encrypted storage with fine-grained access control, comprehensive audit logs, automated rotation, versioning, and dynamic secrets generation on demand. !!Centralization gives visibility into what secrets exist, who accesses them, and when rotation is required!!—access policies enforce least privilege, and encryption, backup, and compliance controls stay consistent across every credential.

Runtime Secrets Injection [Runtime Injection] {2}

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] {2}

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 need secrets to deploy, run tests, and publish artifacts—and those pipeline credentials often carry broad permissions, so they must be treated with the same rigor as production credentials. Modern CI/CD platforms retrieve credentials dynamically at execution rather than storing them in pipeline configuration; access is scoped to specific pipelines using workload identity or OIDC federation, eliminating long-lived service account keys. !!Pipeline definitions never contain secrets—only references!!, and pipelines use just-in-time credentials that exist only for the run and are revoked on completion.

Zero Trust Principles [Zero Trust Principles]

Everything introduced so far—identity, cryptographic proof, authorization, cloud IAM, open protocols, workload identity, and controlled secrets—now comes together as one architecture. !!Zero Trust does not add a new mechanism; it defines how those mechanisms are combined and applied consistently.!!

The previous sections introduced the individual building blocks of trust—and the general design principles they must respect. Zero Trust is not another building block, nor a restatement of least privilege, default deny, time-bound access, or traceability. Those principles are older and apply to any security model. !!Zero Trust is a distinct philosophy about one specific question: what changes when a system stops trusting the network, the location, or the previous request?!! The following four principles answer that question. The next section shows how they combine with the mechanisms of this chapter into a coherent architecture.

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 why the mechanisms introduced earlier are layered together: authenticated identity at the edge, authorization at every service, cryptographic proof between workloads, short-lived credentials, and audit trails. If one layer is bypassed, the others still stand. The question stops being "how do we keep them out?" and becomes "how do we limit what they can reach once they're in?".

Network Location Grants Nothing [Location Grants Nothing] {1}

Being inside a VPC, cluster, or corporate network is not evidence of anything. !!A packet arriving from the "inside" carries no more legitimacy than one from the public internet—both must be authenticated the same way.!! In a Zero Trust architecture, identity replaces network location: authentication is anchored in signed claims, workload identity, and mTLS certificates—mechanisms that travel with the request and are verifiable independently of the network path it took. Network controls (firewalls, security groups, VPCs) still restrict what can reach what, but they no longer answer who is asking. That question belongs to identity.

Every Request Is Verified Independently [Continuous Verification] {1}

The old model verified at the front door and left the visitor alone for hours. Zero Trust makes no such concession: !!every request is evaluated on its own—trust is never carried forward from previous interactions.!! In practice this rests on the mechanisms of the previous sections: signed claims that receivers can verify locally, short-lived credentials that expire before they become dangerous, and workload identity that re-authenticates every connection. A prior authenticated request is not evidence for the next one; a session is not a shortcut. The credential carries the trust, and the policy re-evaluates it each time.

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. This is made possible by the primitives introduced earlier: !!workload identity gives every service its own verifiable name, mTLS turns every service boundary into an authenticated connection, and authorization policies turn each boundary into an access decision.!! Lateral movement becomes expensive, visible, and bounded. Segmentation used to be an IP-address problem; today it is an identity problem.

Zero Trust Architecture [Zero Trust Architecture]

!!Zero Trust is assembled entirely from the mechanisms introduced earlier in this chapter.!! Nothing new appears here; this section simply shows how those mechanisms fit together into one architecture that never grants trust implicitly.

Building a Zero Trust Request [ZT Request Lifecycle] {1}

Every request in a Zero Trust system follows the same lifecycle. !!Identity is established, cryptographic proof is carried, verification happens locally, authorization policy is evaluated, the action executes, and the outcome is audited.!! Nothing in this pipeline is new—each step reuses a mechanism the chapter has already covered. What is new is the discipline: no step is skipped, no step trusts the previous one implicitly, and no request is granted a shortcut because a previous one succeeded. The architecture is the pipeline itself, applied uniformly to every actor, every service, every request.

Identity Replaces Network Location [Identity Over Location] {1}

Users, workloads, devices, and AI agents are all identified individually. !!The network provides connectivity; identity provides trust.!! A packet arriving at a service from another workload in the same VPC carries no more legitimacy than one arriving from the public internet—both must present the same signed proof of identity, verifiable independently of the network path they took. Firewalls, security groups, and VPCs remain useful to control what can reach what, but they no longer answer who is asking. That question is answered by workload identity, mTLS certificates, and signed tokens issued by trusted issuers. In a Zero Trust architecture, the network is plumbing; identity is the perimeter.

Verification Happens at Every Boundary [Verify at Every Boundary] {1}

Zero Trust does not concentrate verification at one gate. !!Every API gateway, every service, every workload, and every cloud resource verifies identity, cryptographic proof, and authorization independently, at its own boundary.!! An edge gateway validates the token; the downstream service revalidates it; the database checks the calling workload's identity again; the audit layer records each decision. This is not redundancy for its own sake—it is what makes Assume Breach real. If any single boundary is bypassed, the next one still holds. There is no interior room in which trust is inherited from having passed the front door.

Policy Is Distributed, Not Embedded [Distributed Policy] {1}

Zero Trust does not require a central authorization service to be called on every request. !!Policy is authored centrally, but enforced locally—the classic separation of Policy Decision Point from Policy Enforcement Point applied at scale.!! A central control plane defines who can do what, under which conditions; each enforcement point (gateway, service, sidecar, cloud IAM) evaluates that policy locally, often against a cached or embedded copy. This is what keeps Zero Trust practical at millions of requests per second: verification is universal, but no request has to make an extra network hop to a central authority to prove it. Central authorship gives coherence; distributed enforcement gives performance and resilience.

Trust Is Scoped and Ephemeral [Scoped Ephemeral Trust] {1}

Every credential in a Zero Trust architecture is narrow and short-lived. !!Trust is granted at the smallest scope it can do useful work, and for the shortest time the work will actually take.!! Workload identity issues per-service credentials, not per-organization ones. mTLS binds trust to a specific connection between two named peers. STS mints tokens that live for minutes. Human access is granted for a task, not a career.

Small in Space, Short in Time [Scope and Time] {1}

Least privilege reduces the spatial footprint of trust; time-boxing reduces its temporal footprint. !!A stolen credential in this architecture is worth almost nothing: it grants little, and it grants it briefly.!! Reducing the duration and scope of trust is not an operational hygiene concern—it is part of the architecture itself.

Putting It All Together [ZT Putting It Together] {1}

Zero Trust is not a new technology—it is an architecture assembled from mechanisms already introduced in this chapter. !!Actor → Authentication (OIDC / mTLS / Workload Identity) → Signed Identity → Local Verification → Authorization Policy → Resource → Audit.!! Every arrow in that chain is a decision made explicitly by a mechanism the chapter already explained. Zero Trust is the discipline that keeps every arrow honest: no arrow is skipped, no arrow is assumed, no arrow inherits trust from another. When every mechanism this chapter introduced is in place and composed this way, the reader has not learned a new pattern—they have finally seen the pattern that has been forming since the first slide.

Operating Trust Infrastructure [Operating Trust]

Designing a trust architecture is one discipline; operating it is another. !!Trust is infrastructure. Infrastructure must be operated. Good platforms automate it.!! The mechanisms introduced in this chapter—identities, certificates, tokens, keys, federations—are not artifacts you deploy once; they are living systems that must be issued, renewed, rotated, revoked, and eventually retired. A trust architecture that assembles the primitives correctly but treats operations as an afterthought is no more secure than one that never adopted them.

Every Identity Has an Authoritative Source [Authoritative Source] {1}

Every identity must be governed by an authoritative source—the system that decides whether the identity exists, what attributes it carries, and when it must change or disappear. For employees, this may be an HR directory; for customers, an identity provider; for workloads, an orchestrator, cloud platform, or workload identity system.

!!The authoritative source is the beginning of the trust lifecycle.!! It triggers provisioning when an actor appears, updates identity and access when its state changes, and initiates revocation when the actor leaves or the workload disappears. Without a clearly defined source of authority, identities become stale, duplicated, and impossible to retire reliably.

Once the source of truth is established, the platform can automate how trust artifacts are issued and maintained.

Operating Trust Is a Platform Responsibility [Platform Responsibility] {1}

Building trust mechanisms is only half of the problem. !!Modern architectures move trust operations into the platform, so applications consume trust instead of managing it.!! An application should not know how a certificate was issued, when it will be renewed, or how it will be revoked—it should only present the credential it was given and trust that the platform keeps that credential alive. This shift is what turns individual trust primitives into an actual architecture: a platform where trust is a service, not a set of tasks distributed across every team.

Trust Infrastructure Is Never Static [Never Static] {1}

!!Trust is not installed once—it lives.!! Identities appear when new users join and new workloads spawn; they disappear when people leave and containers die. Certificates expire on a fixed schedule. Keys are replaced. Authorities are rotated. Federations are re-negotiated. Every trust relationship carries an implicit clock, and every clock eventually strikes. A trust architecture that assumes steady-state is not an architecture—it is a snapshot of a system that has already begun to decay.

Every Trust Model Shifts Operational Complexity [Issuing Trust] {1}

!!Every trust model shifts operational complexity—it never removes it.!! Choosing a mechanism is choosing the operations that go with it: PKI brings certificate authorities, issuance, and revocation; OIDC brings Identity Providers, sessions, and refresh flows; workload identity brings attestation and short-lived credential exchange; secrets bring vaulting and rotation; passkeys bring enrollment, device binding, and recovery. Different mechanisms distribute this cost differently, but none eliminate it. Architects who compare trust mechanisms without weighing their operational surface are comparing incomplete specifications.

Automate the Trust Lifecycle [Automate Trust] {1}

!!Modern platforms automate issuance, renewal, rotation, revocation, and recovery so that applications never manage trust artifacts directly.!! The architectural shift is decisive: operations that used to be tickets and runbooks become properties of the platform, invisible to the workloads that consume them. An application requests a credential and receives one; when it expires, another arrives; when it must be revoked, the platform revokes it. Nothing crosses a human desk. Technologies such as ACME, cert-manager, SPIRE, cloud STS, and Vault are examples of this architectural shift—the principle is not the tooling, it is the movement of trust operations from humans into the platform layer.

Failure and Recovery [Trust Failure & Recovery] {1}

!!A trust system must tolerate the failure of its own trust infrastructure.!! Certificates expire unnoticed. CAs are compromised. Keys must be revoked mid-flight. Identity Providers go down. Each is a real operational event, and each has an architectural answer: overlapping validity windows so renewals are never a cliff, CA rotation ceremonies designed for zero downtime, revocation paths that propagate faster than the credentials they invalidate, and IdP redundancy or short-lived cached tokens so an outage does not cascade into a system-wide outage. A trust architecture is judged less by how it behaves in the happy path than by how it behaves when one of its own foundations breaks.