Zero-trust networking treats every request as untrusted, even when it comes from inside the network. Each user, device, and service must prove its identity before access is granted. This replaces network-location assumptions with continuous verification and explicit authorization. section 16.1 section 16.4
A forged service request
Suppose an exposed Kubernetes debug pod reaches an order, billing, and user service. If billing trusts a header such as X-Service-Name: order-service, an attacker can imitate the order service, create fake invoices, alter amounts, or obtain billing data. A zero-trust design verifies service identity, authenticates the request, and checks whether that service is authorized for the requested action. Options include token verification, request signing, or a service mesh that applies mTLS and identity checks outside application code. section 16.1 section 16.4
A practical zero-trust boundary distinguishes these responsibilities:
- Identity states who the calling service claims to be; authentication checks whether that claim is true. section 16.4
- Authorization determines whether the authenticated service may perform the requested action. section 16.4
- Trust anchors, such as certificate authorities or token issuers, vouch for identities. section 16.4
Figure 16.1 In a system, multiple services communicate to solve various use cases. If the communication isn’t secure, attackers may exploit vulnerabilities and alter or steal data.
Use the service-communication diagram to trace how unverified internal traffic can expose or alter data. section 16.1
