Identity, not network position: the idea zero trust is actually about
Perimeter security assumed that being inside the network meant you were trusted. That assumption failed because the perimeter dissolved and because one compromised host inside it inherited everything. Zero trust replaces network position with verifiable identity as the basis for every decision, and almost every modern security control is an instance of that swap.
TL;DR: Stop deciding access from where a request came from and start deciding it from who is making it, proven cryptographically and re-checked every time. An IP address is not an identity: it is recycled, spoofable and shared, and in a container platform it changes every few minutes.
What the old model assumed
The castle-and-moat design put controls at the boundary: a firewall, a VPN, a DMZ. Inside was trusted, outside was not. It worked while the inside was a building full of desktops.
Two things broke it. The perimeter dissolved, with services in several clouds, employees anywhere and third-party integrations calling in. And once anything inside was compromised, it inherited the trust of being inside, so a single phished laptop or one vulnerable service reached everything. Most large breaches follow that shape: modest initial access, then lateral movement through a network that trusted its own occupants.
What replaces it
Every request is authenticated and authorised on its own merits, regardless of origin. Concretely, four properties:
Verifiable identity. Both humans and workloads carry a cryptographic identity, not an address. For workloads that is a short-lived certificate tied to a service account, issued automatically and rotated frequently. SPIFFE is the vendor-neutral formulation of this idea.
Validate access to each resource, with authentication and authorization at session establishment and policy-driven reevaluation. An authenticated transport session can carry multiple requests; it must not confer unrestricted network trust.
Explicit authorisation, default-deny, expressed in terms of identity: this service may call that service on this operation. Not this subnet may reach that subnet.
Short-lived credentials. Anything long-lived is a secret waiting to leak. Federated, expiring credentials reduce persistent secret storage and bound the useful lifetime of stolen tokens. They can still be stolen and abused before expiry.
Why an IP is not an identity
Worth being concrete, because this is the crux. In a container platform, addresses are drawn from a pool and reassigned within minutes. The address that belonged to a payments pod at noon may belong to a batch job at half past. Policy written against it is therefore correct only for as long as the lease, and nothing tells you when it stops being correct.
That is the mechanical reason network policy is a coarse backstop rather than a security model, and why identity-based authorisation is a different kind of control rather than a better version of the same one.
The shape it takes in practice
The same substitution appears everywhere once you look for it. Workload certificates replacing IP allowlists. OIDC federation from CI to a cloud provider replacing stored access keys. Short-lived database credentials issued per session replacing a shared password. Access brokered per request through an identity-aware proxy replacing a VPN that grants the whole network.
The honest limits
Zero trust is not a product and cannot be bought. It is also not free: you take on certificate lifecycle management, a policy set that grows with every service, and a new failure mode where a misissued policy or an expired CA denies legitimate traffic. Budget for the day the certificate authority expires, because it takes down everything at once.
And the transport half is the easy half. Encryption alone does not identify the caller. Properly validated mutual TLS authenticates both peers; ordinary server-authenticated TLS authenticates the server. Authorization still needs policy for the authenticated identity and requested operation.
Self-check
Does standard Kubernetes NetworkPolicy select service accounts? No: its peer selectors use pods, namespaces and IP blocks. Service-account-aware policy requires another enforcement mechanism, such as an identity-aware proxy or a CNI extension. Why would short-lived CI federation still need narrowly scoped authorization?
Sources: NIST zero trust architecture, Kubernetes NetworkPolicy.