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 grants every user, workload, and token only the permissions required for its task—and only for as long as needed. !!In practice, this means specific roles, narrowly scoped service permissions, and tokens limited to the intended action and resource.!! The goal is not only to prevent misuse, but to bound the damage when an identity or credential is compromised.

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}

!!Most operational credentials should carry an expiry—sessions, access tokens, workload certificates, temporary cloud credentials.!! Their lifetime should be bounded by the task they support—minutes for a request, hours for a session, days 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. Long-lived trust anchors, such as root CAs, are the exception rather than the rule.

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 repeatedly enter passwords or confirm passkeys for every request. !!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]

Authentication proves an identity once. The next challenge is allowing that verified identity to travel across systems without repeating the authentication ceremony. 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. Most modern identity mechanisms in the rest of this chapter—signed tokens, mTLS, SPIFFE, passkeys, workload identity—rest 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 and Verify Independently [Travel and Verify] {1}

Once an identity has been authenticated, a trusted issuer signs claims about that identity and places them in a token. The token travels with each request, carrying the identity and context the receiver needs. !!Each receiver can verify the signature locally using the issuer's public key, without calling the Identity Provider on every request.!!

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.!!

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.

Sensitive Operations Belong in Trusted Environments [Trusted Environments] {1}

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 random web page asking a user to generate their own root CA certificate and private key in the browser is the extreme case of getting this wrong. 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.

IAM Services [IAM Services] {1}

Each major cloud provider packages identity and access management into a centralized model. AWS IAM combines principals, roles, and policies in one service. Azure splits the concern: Microsoft Entra ID manages identities and authentication, while Azure RBAC handles authorization on resources. Google Cloud IAM binds principals to roles on resources. 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 can receive a managed identity, and the platform can prove that identity when the workload calls a supported service. 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 stable identifier within the provider's account, tenant, or project namespace 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.

Open Protocols for Human Trust [Human Trust]

Open protocols let applications establish human identity without handling the user's primary reusable credentials themselves. 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 proof is bound to the legitimate site origin, making passkeys resistant to phishing. !!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 Trust [Workload Trust]

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 establish trust 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. In many cases, that proof is also used to authorize the workload to obtain a temporary identity or role before it accesses cloud resources. Workload protocols define how software establishes trust, authenticates itself, and, when required, obtains the credentials needed to act.

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—the SVID—for those certificates. SPIRE is the reference implementation that attests workloads and automatically issues and rotates their SVIDs. 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.

SPIFFE Federation [SPIFFE 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.

Assuming a Cloud Role using OIDC Federation [OIDC Federation]

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. The trust policy authorizes the workload to assume the role; the permissions attached to that role determine what the workload can do afterward.

Multiple Flows Can Obtain Temporary Cloud Credentials [Multiple Flows] {1}

The previous example used OIDC federation to obtain short-lived credentials from a cloud provider. It is one of several authentication flows that can produce temporary cloud credentials. A workload may also authenticate using OAuth 2.0 Client Credentials with a client secret or a client certificate. !!The destination is the same: short-lived credentials used to perform cloud operations. What differs is how the workload proves its identity.!! OIDC federation is generally preferred because it eliminates the need to provision, store, protect, and rotate long-lived credentials.

Decoupling Confidentiality from Authenticity [From Secrets to Proof]

Modern systems can establish trust in two fundamentally different ways: by relying on a shared secret, or by verifying cryptographic proof. This section explains why modern architectures increasingly favor proof over reusable secrets, and how shared secrets should be minimized and carefully managed when they remain necessary.

Confidentiality vs Authenticity [Two Concerns] {1}

Confidentiality and authenticity 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. Authenticity 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. !!The data no longer has to remain secret. The key does.!!

Authenticity and Integrity [Proving Origin]

Unlike confidentiality, authenticity 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 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.

Authenticity Treated as Confidentiality [Locked Message]

Before digital signatures made authenticity and integrity independently verifiable, systems often treated both as confidentiality problems. !!Messages were placed inside encrypted containers—portable safes protected by shared keys. If a receiver could decrypt the message, the sender was assumed legitimate; if the message decrypted correctly, it was assumed unchanged.!! Secrecy became a substitute for both identity and tamper detection—not because it was the right model, but because better proof was not yet practical.

Authenticity: The Bootstrap Problem [Bootstrap]

Beyond the operational cost, shared secrets face a deeper theoretical problem: 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.

Authenticity: A New Paradigm—From Secrets to Proofs [New Paradigm] {1}

A fundamental shift moved trust away from shared secrets toward cryptographic proof. 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. !!This fundamentally decouples authenticity and integrity from confidentiality: a message can travel over an untrusted or even public channel while its origin and integrity remain independently verifiable through cryptographic proof.!! Identity becomes the anchor of trust—no longer bound to the channel, but carried by the message itself, verifiable anywhere.

Zero Trust [Zero Trust]

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.!! It is a distinct philosophy about one specific question: what changes when a system stops trusting the network, the location, or the previous request? The four principles below answer why; the architectural slides that follow show how those principles compose into a concrete architecture, ending with a checklist a reader can hold their own system against.

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, authentication is anchored in cryptographic identity rather than network location. 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.!! A prior authenticated request is not evidence for the next one; a session is not a shortcut. Each request presents its own proof of identity, and the policy re-evaluates it each time — verification is a property of every request, not of an initial handshake.

Microsegmentation: Contain the Blast Radius [Microsegmentation] {1}

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. !!Each service authenticates its caller and evaluates authorization independently. Compromising one workload no longer grants access to the rest of the system.!! Lateral movement becomes expensive, visible, and bounded. Segmentation used to be an IP-address problem; today it is an identity problem.

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

!!Zero Trust is not a new technology — it is the consistent application of the mechanisms introduced throughout this chapter to every request.!! Every request follows the same lifecycle: establish identity, carry cryptographic proof, verify locally, evaluate policy, execute, and audit. No shortcuts. No inherited trust.

Define Policy Centrally, Enforce It Everywhere [Policy Distribution] {1}

Authorization rules should be defined in one place, then distributed to the systems that handle requests. !!API gateways, services, databases, sidecars, and cloud IAM evaluate authorization locally using centrally managed policies.!! This keeps authorization consistent without requiring a central authorization call for every request.

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

Every credential has two properties: what it can do, and how long it remains valid. Zero Trust minimizes both. Credentials authorize as little as possible, and they remain valid for as little time as possible. A stolen credential therefore has very limited value: it grants little, and only briefly. Least privilege reduces the scope of a credential. Short-lived credentials reduce its lifetime. Together, they minimize the damage a stolen credential can cause.

Building a Zero Trust Architecture [ZT Checklist] {1}

Zero Trust is not a product or protocol. It is an architectural style built from identity, cryptographic proof, local authorization, distributed policy, short-lived trust, and auditability. Before calling an architecture Zero Trust, ask: is every actor identified, every request proven and verified, every decision authorized locally, and every grant narrow, short-lived, and auditable? Every “no” reveals a missing building block.

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, databases, and CI/CD pipelines still depend on them. !!For those that remain, the goal shifts from avoiding secrets to containing their risk!!: minimize their number and spread, centralize control, automate their lifecycle, decouple applications from retrieval, and propagate refreshed values at runtime. This section is the playbook for that containment.

Eliminate Shared Secrets Wherever Possible [Eliminate Secrets] {1}

Every shared secret is a liability: it must be stored, copied, rotated, and eventually exposed. !!The goal is not merely to manage shared secrets better, but to eliminate them wherever identity-based authentication can replace them.!! With mTLS, workload identity, or OIDC federation, each party proves possession of its own credential instead of exchanging a reusable secret. Cryptographic material still exists, but it is not shared or managed by application code. "Secretless" means no application-managed shared secret — not no cryptographic keys.

Shared Secrets Create Sprawl [Secrets Sprawl] {1}

Every shared secret must be issued, stored, protected, rotated, and revoked across every system that uses it. !!Least privilege often requires separate credentials for each service or workload, causing secrets to spread across configuration files, environment variables, CI/CD systems, container platforms, and developer machines.!! Each copy increases operational cost and creates another exposure point. Once an organization no longer knows where every copy exists, rotation becomes unreliable and leaked credentials may remain valid.

Centralized Secrets Management Systems [Centralized Systems]

Centralized platforms—such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Secret Manager—provide a single source of truth for credentials. Each secret has one canonical location; copies in configuration files, environment variables, or CI systems are temporary, revocable projections. These platforms provide encrypted storage, fine-grained access control, audit logs, versioning, rotation, and dynamic secret generation. Centralization restores visibility, enforces least privilege, and keeps security and compliance controls consistent.

The Secret Lifecycle Must Be Automated [Lifecycle Automation] {1}

Centralizing secrets is not enough — if their lifecycle still depends on humans, the platform inherits the very risk it was meant to remove. !!Generation, delivery, renewal, rotation, and revocation are highly sensitive operations and must be automated wherever the platform permits.!! Manual workflows are slow, inconsistent, and eventually skipped when rotation risks disrupting production. Automation keeps humans away from raw credentials and makes short lifetimes practical.

Secrets Are Scoped to Isolation Boundaries [Scoped Secrets] {1}

Every secret belongs to an isolation boundary — tenant, environment, cloud account, or region. !!A secret's blast radius equals the scope where it lives; a leak in one boundary cannot compromise the others.!! Sharing a secret across boundaries fuses their blast radii and must be an explicit, governed decision — not a convenience. By default, each scope holds its own independently generated and rotated copy.

Secret Retrieval Should Be Decoupled from Applications [Decoupled Retrieval] {1}

Applications should not authenticate directly to a secrets manager or depend on its API. !!The platform authenticates the workload, retrieves its authorized secrets, and exposes them through a local interface such as a mounted file, memory-backed volume, or local agent.!! Build and deployment artifacts contain only references to required secrets, never the secret values themselves. The application consumes secrets without knowing where they are stored or how access is obtained.

Secrets Must Be Refreshable at Runtime [Refreshable Secrets] {1}

Providing a secret only at startup makes it static for the lifetime of the process. Updating the value in the secrets manager is not enough if the application continues using the previous one. !!The platform should propagate refreshed secrets automatically, and applications should adopt the new value without rebuilding or restarting.!! This applies to every kind of sensitive material — API keys, database passwords, TLS certificates, mTLS client certs — a rotated cert the process never re-reads will silently break authentication mid-request. Rotation requires propagation on both sides: the platform writes the new value, the application picks it up.

Secrets in CI/CD Pipelines [CI/CD Secrets] {1}

CI/CD pipelines need broad credentials to deploy, test, and publish — treat them as production credentials, not build-time conveniences. !!Pipeline definitions carry references, never secrets; the pipeline exchanges its workload identity for short-lived credentials scoped to the run, then they are revoked.!! No long-lived service account keys, no secrets committed to the repo.

Operating Trust

Throughout this chapter we focused on how trust is established — identities, authentication, authorization, cryptographic proof, protocols, secrets, and the Zero Trust stance that ties them together. !!The next challenge is operating that trust throughout the lifetime of the system.!! Identities appear and disappear, certificates expire, keys rotate, authorities are compromised, federations are renegotiated. A trust architecture is judged not only by how correctly it assembles the primitives, but by how faithfully it operates them once the system is running.

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 is 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 access when its state changes, and initiates revocation when the actor leaves.!! Without a clearly defined source of authority, identities become stale, duplicated, and impossible to retire reliably — the whole downstream platform inherits ambiguity that no rotation or automation can fix.

Every Trust Artifact Runs on Its Own Clock [Trust Lifecycles] {1}

Identities, certificates, keys, tokens, and federations each follow their own independent lifecycle. !!An identity is provisioned and retired; a certificate is issued, renewed, and revoked; a key is generated, rotated, and replaced; a token lives for minutes and is reissued continuously; a federation is established, renegotiated, and eventually terminated.!! At any moment, every artifact in the system sits somewhere on its own timeline — none of them steady, all of them evolving. Operating trust means designing for this continuous motion, not for the frozen state of the day the system was deployed.

Every Trust Model Moves Complexity Somewhere Else [Complexity Relocation] {1}

Good architecture removes unnecessary complexity and deliberately places what remains. Every trust mechanism eliminates one operational burden while introducing another: PKI removes shared-secret distribution but requires certificate lifecycle management; OIDC removes authentication logic from individual applications but creates a dependency on the IdP; SPIFFE eliminates manual certificate provisioning but requires attestation infrastructure; Vault reduces secret sprawl but becomes a critical system itself. Choosing a trust model means deciding which complexity can be removed and where the remaining complexity should live. Architects who evaluate mechanisms only on cryptographic elegance see only half the picture—the other half is the operational surface they create.

Platforms Operate Trust [Platform Operates Trust] {1}

!!Applications should consume trust — platforms should operate it.!! An application should not know how a certificate was issued, when it will renew, or how a workload identity is attested; it should only present the credential the platform gave it and trust that the platform keeps it alive. Everything the trust lifecycle demands — provisioning, issuance, renewal, rotation, revocation, federation, auditing — is a property of the platform, not a checklist inside each service. Automation is not an optimization here, it is the architecture: the moment any trust operation requires a human to be online, the system stops scaling with the number of workloads and starts scaling with the number of engineers.

Designed to Survive Its Own Failures [Trust Failure & Recovery] {1}

!!A trust architecture is judged by how it behaves when one of its own foundations breaks.!! Every mechanism eventually fails: certificates expire unnoticed, CAs are compromised, keys must be revoked mid-flight, Identity Providers go down, federations break, rotations fail mid-flight, credentials are stolen. Each is a real event that will happen, and each has an architectural answer — overlapping validity windows so renewals are never a cliff, standby CAs prepared for zero-downtime rotation, revocation paths that propagate faster than the credentials they invalidate, IdP redundancy and short-lived cached tokens so a provider outage does not cascade, blast radius limited so a compromised identity cannot reach beyond its scope. The happy path is not the design. The failure path is.

Trust Is the Substrate of Distributed Systems [Chapter Conclusion] {1}

The mechanisms in this chapter — identity, authentication, authorization, cryptographic proof, protocols, secrets, Zero Trust — are not a checklist to configure once. Together they form the substrate that lets a distributed system keep answering the only question that matters: !!who is doing what, right now, and are they still allowed to.!! Everything else in a distributed architecture — traffic routing, data storage, business logic, scaling — assumes that this question has a correct, continuous, and enforceable answer. Trust is not a security concern layered on top of the system; it is the foundation the system stands on.