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 as pods come and go. The address that belonged to a payments pod at noon may belong to a batch job by half past, and nothing announces the handover.
Put a rate on it. Take a node subnet with 254 usable addresses running 60 pods, in a cluster where deployments, autoscaling and evictions replace roughly 200 pods a day on that node's range. The pool cycles through its addresses about 200 / 254 ≈ 0.8 times a day, so a specific address is reused every day or two on average, and an address freed while the pool is near exhaustion can be reissued in seconds. Any allowlist entry naming an address is therefore an assertion with a shelf life of about a day, written in a file that has no expiry date.
Two things follow that a rate makes obvious. The first is that the rule does not merely stop working, it starts working for the wrong workload: when the batch job inherits the payments pod's address, it inherits the access that was granted to that address. The second is that nothing detects this. A stale allowlist entry produces no error, no log line and no failed request, because from the enforcement point's view the packet matches the rule exactly as written. It is a permission that silently changes owner.
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. A certificate tied to a service account cannot be inherited by whatever starts next, because it expires and is issued to a name rather than to a location.
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
You are asked to enforce that only the payments workload may call the ledger service, and a colleague proposes a Kubernetes NetworkPolicy selecting the payments pods. Say whether that policy expresses the rule you were asked for, and what it actually expresses instead. Then answer a second question: a CI pipeline has been moved from a stored cloud access key to OIDC federation with credentials that last fifteen minutes. Why does that change still need narrowly scoped authorisation to be worth much? Work both through before reading on.
The policy does not express the rule, and the gap is specific. Standard NetworkPolicy peer selectors work on pods, namespaces and IP blocks; they do not select service accounts. So the policy says that traffic from pods carrying a particular label may reach the ledger service, and a label is an assertion made by whoever created the pod rather than a credential anybody verified. It also authorises a connection rather than an operation, so it cannot distinguish a read from a write, and it is enforced on network reachability rather than on the request. Selecting service accounts needs a different enforcement mechanism, such as an identity-aware proxy or a CNI extension that understands workload identity. The policy is still worth having as a backstop that reduces what a compromised pod can reach; it is not the control you were asked for.
The CI question turns on the difference between a credential's lifetime and its power. Fifteen-minute federation removes the standing secret, which is a real improvement, because there is no longer a long-lived key in a settings page waiting to be exfiltrated. What it does not do is reduce what the credential can do while it is alive. If the federated role can write to any bucket and modify any function, then a compromised build step, a malicious dependency or an injected script in a pull request workflow has full administrative access for fifteen minutes, which is ample. Short lifetime bounds the window; scope bounds the damage inside it, and only the pair is useful. The general form is the same substitution this page is about: you have replaced a secret with an identity, and an identity still needs a policy saying what it may do.
Next: service-to-service authentication designs the control this page argues for, and zero trust in Kubernetes works through what the platform can and cannot enforce.
Sources: NIST zero trust architecture, Kubernetes NetworkPolicy.