Be Wise Apps
Leer en español · Lire en français · Auf Deutsch lesen
Section 8.5 of 8.8 · Advanced · 22 min read
Secure communication and zero trust
Video lesson
5 min · narrated, with captionsListen only (audio)
Read the transcript
For decades, anything inside the company network was treated as friendly. This lesson explains why that stopped working, and what zero trust puts in its place.
Imagine a hotel where the front desk checks your identity once, then hands you a key that opens every room. If a thief gets past the desk, every room is open. A better hotel gives you a key card that opens only your room, only for the nights you booked. And it records every door it opens. Zero trust applies that second idea to software. Every person and every program must prove who it is, and be allowed to do that particular thing, every time.
The old model was a castle with a moat. A firewall kept out the internet, and services inside called each other with no authentication, because the network itself was the credential. But one phishing email or stolen password puts an attacker inside the moat. From there they move sideways from machine to machine. That's called lateral movement. The inside also dissolved. Workloads now run across several cloud accounts, outside services and partner APIs, so there's no single wall to defend. And it became dynamic. Containers appear and disappear every minute, and network addresses are reused, so firewall rules written as addresses describe nothing stable.
The reference definition comes from NIST, published in 2020. No implicit trust is granted to a user or asset based only on where it sits on the network, or who owns it. All communication is secured, even inside the data centre. Access is granted per session, with least privilege, and decided by dynamic policy. The slogan is: never trust, always verify.
Here is the machinery NIST describes. A subject, which may be a user or a workload, reaches a resource only through a policy enforcement point. Nothing is trusted because of where on the network it comes from. The enforcement point asks the policy decision point. Its policy engine decides, grant or deny, and its policy administrator opens or ends the session. The decision draws on the identity provider, the state of the device, threat intelligence, the access policy and activity logs. For an architect, the questions are where to put enforcement points so there's no path around them, and how to keep decisions fast and available. If the decision point can't be reached, the normal answer is deny.
Zero trust between services needs encryption and a strong identity at both ends of every call. Ordinary HTTPS only proves who the server is. In mutual TLS, the calling service presents a certificate too, so the server knows which workload is calling. Network addresses are poor identities for containers. An open standard gives each workload a named, short-lived identity, renewed automatically, so a rule can say orders may call payments, instead of naming addresses. A service mesh can automate this, at a real operational cost. And every certificate needs automated renewal. Expired certificates are one of the commonest causes of avoidable outages, and public certificate lifetimes are getting much shorter.
Before, on a flat internal network, any host can reach any port, and every service shares one database. When the menu service is compromised, it can reach payments directly. After, each service has its own data, and only named identities may make allowed calls. Orders calls payments over mutual TLS, with a policy. The compromised menu service tries the same call, and it's denied. Zero trust doesn't stop a service being compromised. It limits what that service can reach.
Here's how the platform's twenty or so services moved to zero trust, in stages that can each be reversed. First, observe the real traffic. That revealed a surprise: the analytics job was reading the payments database directly. Second, give every service its own identity, and replace the shared database account with one credential per service. Third, switch on strict mutual TLS one part of the system at a time, starting with the lowest risk. Fourth, write allow rules from the calls you observed. Run them in audit mode for two weeks, review what would be denied, then enforce. Fifth, put staff tools behind an identity-aware proxy that checks the person and the device, and switch off the virtual private network. Sixth, keep it true: the build fails if a new service has no policy. Notice the order: observe before enforcing, identity before policy, audit before deny.
The full section has NIST's seven tenets, Google's BeyondCorp, and what an API gateway can and can't do. Next, in Section eight point six, we look at the security of your software supply chain. See you there.
What you need to know
- The perimeter model trusts anything inside the network, so one stolen credential or compromised machine allows lateral movement; cloud, mobile and remote work have also removed any single perimeter to defend.
- NIST SP 800-207 (August 2020) defines zero trust as granting no implicit trust based on network location or ownership, with seven tenets including securing all communication, per-session access and dynamic, strictly enforced policy.
- A policy enforcement point in front of each resource asks a policy decision point (policy engine plus policy administrator), which decides using identity, device or workload posture, threat data and policy.
- Google's BeyondCorp (2014) applied zero trust to staff access with device inventory, an access proxy and trust tiers, and removed the privileged office network and the VPN.
- Mutual TLS gives every service call encryption and a verified identity at both ends; SPIFFE standardises short-lived workload identities, and service meshes automate mTLS and per-call policy at a real operational cost.
- Certificates must be issued and renewed automatically (ACME, RFC 8555), especially as public TLS certificate lifetimes fall to 200 days in 2026, 100 days in 2027 and 47 days in 2029.
- API gateways authenticate tokens, rate-limit and validate input, but object-level authorisation must still happen in the service that owns the data.
Why the network perimeter stopped working
For decades most organisations protected their systems like a castle with a moat. A firewall separated the trusted inside from the untrusted internet, staff connected to the inside through a virtual private network (VPN), and anything already inside was treated as friendly. Services in the data centre called each other over plain HTTP with no authentication, because the network itself was the credential. Chapter 6 listed the network is secure
among the fallacies of distributed computing; the perimeter model is that fallacy turned into an architecture.
Three things broke it. First, the inside became too large to defend: laptops travel, staff work from home, partners connect, and a single phishing e-mail or stolen VPN password puts an attacker inside the moat. Once there, the attacker moves sideways from machine to machine, which is called lateral movement. In the 2013 breach at the US retailer Target, attackers first used network credentials stolen from a heating and ventilation contractor and from there reached the payment terminals, taking data on about 40 million cards. Second, the inside dissolved: workloads now run across several cloud accounts, SaaS products and third-party APIs, so there is no single wall to put a firewall on. Third, the inside became dynamic: containers appear and disappear every minute and IP addresses are reused, so rules written as allow 10.0.4.0/24 to reach 10.0.7.12 describe nothing stable.
The idea that the perimeter should be abandoned is older than the name. The Jericho Forum, a group of corporate security officers, argued for de-perimeterisation from 2004; John Kindervag, then an analyst at Forrester Research, coined zero trust around 2010; and Google's BeyondCorp papers from 2014 showed it working at scale. The slogan is never trust, always verify: no request is trusted because of where it comes from.
Zero trust as NIST defines it
The reference text is NIST Special Publication 800-207, Zero Trust Architecture, published in August 2020 (Rose, Borchert, Mitchell and Connelly). It describes zero trust as a set of principles that move defences from static, network-based perimeters to users, assets and resources, and a zero trust architecture as an organisation's plan for applying them. Its central claim is that no implicit trust is granted to an asset or user account based only on its physical or network location or on who owns it. Authentication and authorisation are discrete functions performed before a session to a resource is established.
The publication lists seven tenets. They are worth knowing in their own words because many products claim to be zero trust while meeting only one or two of them.
The seven tenets of NIST SP 800-207, with the food-delivery platform
| Tenet (paraphrased) | What it means | Food-delivery example |
|---|---|---|
| 1. All data sources and computing services are resources | A laptop, a container, a SaaS tool and a database are all things to protect, not only servers in the data centre. | The courier app's backend, the restaurant tablet API and the analytics bucket are each resources with their own policy. |
| 2. All communication is secured regardless of network location | Traffic inside the data centre gets the same encryption and authentication as traffic over the internet. | Orders calls Payments over mutual TLS even though both run in the same cluster. |
| 3. Access is granted per session | Trust is evaluated for each session with the least privilege needed, and granting one resource grants nothing else. | A support agent's session can read one customer's order history; it cannot also reach the refunds API. |
| 4. Access is decided by dynamic policy | The decision uses the identity, the state of the device or workload and other attributes such as time, location and behaviour. | A refund over a set amount from an unmanaged laptop is refused; the same request from a managed device with fresh MFA is allowed. |
| 5. The enterprise monitors the integrity and posture of all assets | No device or workload is trusted by default; its patch level, configuration and integrity are measured continuously. | A container image without a valid signature, or with a critical unpatched CVE, is not admitted to the cluster. |
| 6. Authentication and authorisation are dynamic and strictly enforced before access | Identity is checked before every access and re-checked during long sessions; credentials are short-lived and rotated. | Service certificates live for hours and are renewed automatically; user sessions are re-evaluated when risk changes. |
| 7. The enterprise collects as much information as possible about the state of assets, network and communications | Telemetry feeds back into the policy so that decisions improve over time. | Access logs from the gateway, the mesh and the identity provider flow to the security monitoring platform. |
Policy decision and enforcement points
SP 800-207 describes the machinery with a small set of logical components. A policy enforcement point (PEP) sits in front of a resource and lets traffic through only when told to: in practice an identity-aware proxy, an API gateway, a service mesh sidecar or a database proxy. The policy decision point (PDP) makes the decision. NIST splits it into a policy engine, which evaluates the request against policy and inputs and decides, and a policy administrator, which carries out the decision by opening or closing the path, for example by issuing a short-lived session token or configuring the PEP. The inputs include the identity provider, device and workload posture (patch level, configuration, integrity), threat intelligence, the access policies themselves and activity logs.
Separating decision from enforcement is the same move as separating policy from mechanism in operating systems, and it pays off for the same reason: policies can be written once, reviewed, tested and changed centrally, while enforcement is spread to every place traffic flows. The policy engines of Section 8.3, such as Open Policy Agent, are often the engine behind a PDP. The design question for an architect is where to put the enforcement points so that there is no path around them, and how to keep the decision fast and available, because a PDP on the critical path of every request is now a dependency with its own availability and latency budget. Common answers are to cache decisions for seconds, to push compiled policies to the PEP so that it can decide locally, and to decide in advance what happens if the PDP is unreachable (normally deny, with a small allow-list for health checks).
The logical components of a zero trust architecture
BeyondCorp: zero trust for people
Google began moving away from its privileged corporate network after the 2009 intrusion known as Operation Aurora and described the result in BeyondCorp: A New Approach to Enterprise Security (Rory Ward and Betsy Beyer, ;login:, December 2014), followed by several further papers. The design has three main parts. Every device is enrolled in a device inventory and identified by a certificate. An access proxy, reachable from the internet, fronts every internal application; employees reach applications through it from any network, including the office network, which gets no special privileges. A trust inference component combines who the user is with the state of the device to assign a trust tier, and each application declares the minimum tier it requires.
The consequence that surprised people was the removal of the VPN: an employee in a café and an employee at a desk in the office go through the same checks. The idea now ships as products under the names identity-aware proxy and zero trust network access (ZTNA). The US Cybersecurity and Infrastructure Security Agency's Zero Trust Maturity Model (version 2.0, April 2023) is a useful self-assessment tool: it scores five pillars (identity, devices, networks, applications and workloads, and data) from traditional to optimal, with visibility, automation and governance across all of them.
Mutual TLS, certificates and workload identity
Zero trust between services needs two things on every call: encryption, and a strong identity for both ends. Transport Layer Security does both. TLS 1.3 (RFC 8446, August 2018) completes its handshake in one round trip: the client sends its supported algorithms and a key share, the server answers with its key share and its certificate, and both derive session keys with ephemeral Diffie-Hellman, so every session has forward secrecy (a stolen server key cannot decrypt recorded past traffic). TLS 1.3 removed the weak options of earlier versions, including RSA key exchange, CBC-mode ciphers, RC4, SHA-1 signatures, compression and renegotiation; TLS 1.0 and 1.1 were formally deprecated by RFC 8996 in 2021. An optional zero round-trip (0-RTT) mode lets a returning client send data immediately, but that early data can be replayed by an attacker, so it must be limited to idempotent requests. Major browsers and cloud providers have also begun using hybrid post-quantum key exchange that combines X25519 with ML-KEM (standardised by NIST as FIPS 203 in 2024), which protects today's recorded traffic against a future quantum computer.
A certificate binds a public key to a name and is signed by a certificate authority (CA); the client checks the chain of signatures up to a root it already trusts. This system of CAs, certificates, trust stores and revocation is a public key infrastructure (PKI). Public certificates are also logged in Certificate Transparency logs, so a mis-issued certificate for your domain can be spotted. Ordinary HTTPS authenticates only the server. In mutual TLS (mTLS) the client also presents a certificate, so the server learns which workload is calling. Internal certificates come from a private CA that the organisation runs, usually inside its secrets or mesh platform, because public CAs will not issue certificates for internal names.
What name goes in the certificate? Hostnames and IP addresses are poor identities for containers. SPIFFE (Secure Production Identity Framework for Everyone, a graduated project of the Cloud Native Computing Foundation) standardises workload identity: each workload gets a URI such as spiffe://fooddelivery.example/ns/prod/sa/orders and a short-lived SPIFFE Verifiable Identity Document, either an X.509 certificate for mTLS or a JWT. Its reference implementation, SPIRE, attests a workload (checks which Kubernetes service account or cloud instance it really is) before issuing the document, and rotates it automatically, typically every hour or so. Authorisation rules can then say orders may call payments instead of naming addresses.
Service meshes
Implementing mTLS, certificate rotation, retries and per-call authorisation inside every service, in every language, is expensive and inconsistent. A service mesh moves that work into infrastructure. In the classic design each service instance gets a sidecar proxy (Envoy in Istio, a Rust micro-proxy in Linkerd) that intercepts its traffic; a control plane issues identities, distributes policies and collects telemetry. Newer sidecar-less designs, such as Istio's ambient mode, put a shared per-node proxy in charge of mTLS and add a separate proxy only where HTTP-level policy is needed. NIST SP 800-207A (September 2023) describes this pattern as the way to apply zero trust to cloud-native applications: identity-based segmentation, with policies enforced by the mesh at every call.
A mesh is a significant platform decision. It adds latency per hop (usually small, but measurable at the p99), memory per pod, a control plane that must itself be highly available and secured, and a learning curve for every team. It also only protects traffic that goes through it: a job that connects directly to the database bypasses it. Small systems with a handful of services often do better with mTLS provided by a library or the platform's load balancers. The deciding questions are how many services and languages you have and whether a platform team exists to run it (see Section 10.7).
Automating certificates
Certificates expire, and expired certificates are one of the most common causes of avoidable outages. On 6 December 2018 an expired certificate in Ericsson software used by the UK mobile network O2 left about 32 million customers without data service for most of a day. The cure is automation. The ACME protocol (Automatic Certificate Management Environment, RFC 8555, 2019), developed for the Let's Encrypt certificate authority, lets software prove control of a domain (by serving a token over HTTP, adding a DNS record or answering a TLS challenge), obtain a certificate and renew it without a person involved. Let's Encrypt, a free, non-profit CA that began issuing certificates in 2015, made short-lived, automatically renewed certificates the norm; tools such as cert-manager do the same inside Kubernetes, and every major cloud load balancer can manage certificates for you.
Automation is no longer optional. Under CA/Browser Forum ballot SC-081, the maximum lifetime of publicly trusted TLS certificates fell to 200 days for certificates issued from 15 March 2026, and falls to 100 days from 15 March 2027 and 47 days from 15 March 2029. Short lifetimes limit the damage of a stolen key and reduce reliance on revocation, which has always worked poorly. Architecturally this means every certificate, public or internal, needs an owner, automated renewal, monitoring of expiry dates with alerts well before the deadline, and a rehearsed manual fallback.
Segmentation and microsegmentation
Zero trust does not mean the network no longer matters; it means the network is no longer the only control. Network segmentation divides infrastructure into zones with controlled paths between them: public subnets for load balancers, private subnets for services, isolated subnets for databases, and separate cloud accounts for production, staging and security tooling. Microsegmentation shrinks the zones to single workloads, so each service may receive traffic only from the callers it needs and may send traffic only to its declared dependencies.
In Kubernetes, all pods can reach all other pods unless NetworkPolicy resources restrict them, so the first step is a default-deny policy per namespace followed by explicit allows. Egress (outbound) control is as important as ingress: a compromised service that cannot open connections to the internet cannot easily send stolen data out or download further tools. Cloud security groups, Kubernetes network policies and mesh authorisation policies work at different layers (addresses and ports, pods and labels, workload identities and HTTP methods) and are best used together: the outer layers give coarse protection that survives a mesh misconfiguration, the inner layer expresses intent precisely. This is defence in depth (Section 8.1) applied to the network.
From a flat network to identity-based segmentation
Securing the API gateway
The API gateway is the main enforcement point between the internet and the services, so it carries several duties. Authentication: terminate TLS, then validate every access token (signature with a pinned algorithm, issuer, audience, expiry and not-before time), reject requests without one, and pass a verified identity, never the raw client claims, to the services. Rate limiting: limit requests per client, per user and per route, usually with a token bucket, answering HTTP 429 with a Retry-After header; separate, stricter limits protect login, password reset and voucher redemption from credential stuffing and enumeration. Input validation: enforce maximum request sizes and header counts, accept only the declared content types, and validate bodies against the OpenAPI schema so malformed requests never reach a service. A web application firewall can add generic attack signatures, but it is a supplement, not a substitute for correct code.
Know what a gateway cannot do. It sees the route and the token, but not whether order 81723 belongs to the customer asking for it. Broken object level authorisation, where a user changes an identifier in the URL and reads someone else's data, has been first in the OWASP API Security Top 10 in both its 2019 and 2023 editions, and only the service that owns the data can prevent it. Services must therefore authorise every request themselves, using the verified identity the gateway forwards. When a service calls another on a user's behalf, it should pass a token that names both the user and the calling service, for example obtained through OAuth 2.0 token exchange (RFC 8693), rather than its own all-powerful credential; otherwise a bug in one service turns it into a confused deputy that can act for anyone.
Worked example
Worked example: moving the food-delivery platform from a flat network to zero trust
The platform runs about twenty services in one Kubernetes cluster and one cloud account. Services call each other over plain HTTP, a shared database user is used by six services, staff reach the admin console over a VPN, and the threat model in Section 8.2 flagged lateral movement after any single compromise as the top risk. A big-bang switch would break traffic, so the migration is staged and each step is reversible.
| 1. Inventory and observe (weeks 1 to 3) | List every service, its owner and its callers. Install the mesh in permissive mode, which accepts both plain and mTLS traffic, and use its telemetry to build the real call graph. Surprise found: the analytics job calls the Payments database directly. |
|---|---|
| 2. Give every workload an identity (weeks 3 to 5) | One Kubernetes service account per service; the mesh issues SPIFFE certificates valid for 24 hours, rotated automatically. The shared database user is replaced by one credential per service, issued by the secrets manager for an hour at a time. |
| 3. Encrypt everything (weeks 5 to 8) | Switch namespaces one at a time to strict mTLS, starting with low-risk ones. Dashboards show any remaining plain-text callers; each is fixed before its namespace flips. Rollback is one configuration change per namespace. |
| 4. Authorise every call (weeks 8 to 12) | Write allow-policies from the observed call graph: Orders may call Payments on POST /authorisations; Menu may call nothing in Payments. Run them in audit mode for two weeks, review the denials, then enforce. Add default-deny Kubernetes NetworkPolicies and egress rules as an outer layer. |
| 5. Replace the VPN for staff (weeks 10 to 16) | Put the admin console and internal tools behind an identity-aware proxy that requires single sign-on, phishing-resistant MFA and a managed, patched device. Refunds above a threshold need a fresh MFA step. The VPN is switched off once nothing uses it. |
| 6. Harden the edge (in parallel) | The gateway validates tokens, applies per-route rate limits and schema validation, and forwards a verified identity; each service still checks that the caller may see the specific order or account. |
| 7. Measure and keep it true | Fitness functions fail the build if a new service has no authorisation policy, and alerts fire on denied calls and on certificates within seven days of expiry. Every new dependency is a reviewed policy change. |
The order matters: observe before enforcing, identity before policy, audit mode before deny. Each step can be rolled back on its own, which keeps the risk of the migration lower than the risk it removes.
The result is not that nothing can be breached. A compromised Menu service can still misuse its own data and the calls it is allowed, but it can no longer reach payments or other services' databases, and its attempts are logged and alerted on.
Questions people ask
Do we still need a VPN?
For people reaching web applications, an identity-aware proxy usually replaces it. VPNs or private links remain reasonable for site-to-site connections and for protocols a proxy cannot handle, but they should not grant broad trust to whatever is on the other side.
Is a service mesh required for zero trust?
No. It is one convenient way to get mTLS, workload identity and per-call policy everywhere. Platform load balancers, libraries and cloud identity features can achieve the same for a small number of services.
Does zero trust make the system slower?
Each check adds a little latency, typically well under a millisecond for a local mesh proxy and a few milliseconds when a remote decision is needed. Caching decisions, pushing policy to the enforcement point and reusing connections keep it small; measure it at p99 on critical paths.
Check your understanding
Why does mutual TLS between services, with every service allowed to call every other, fall short of zero trust?
It provides encryption and identity, but no authorisation. A compromised service can still call anything; zero trust needs a per-call policy that allows only the calls each identity actually requires.
What is the difference between the policy engine and the policy enforcement point?
The policy engine decides whether a request should be allowed, using policy and inputs such as identity and posture; the enforcement point sits in the traffic path and applies that decision by allowing or blocking the request.
Why are short-lived certificates attractive, and what do they demand?
A stolen key is useful only until the certificate expires, which reduces reliance on revocation. They demand fully automated issuance and renewal, plus monitoring of expiry.
A customer changes the order number in a URL and sees another customer's order. Which component should have prevented it?
The service that owns orders, by checking that the authenticated customer owns that specific order. The gateway authenticated the user correctly but cannot know who owns each object.
Sources and further reading
Have a question about this section? ArchitectBot, the course’s AI study assistant, answers from the course first.
Ask: “How would I introduce mutual TLS and per-service authorisation into an existing Kubernetes system without breaking traffic?”