Zero-Trust Networking
Zero-trust is a security model that removes implicit trust from network location. Every request — even from inside the corporate network — must be authenticated and authorized before access is granted.
Zero-trust = an airport where everyone goes through security at every gate, not just the entrance. Being 'inside the building' doesn't mean you skip the metal detector.
Traditional 'castle and moat' security trusts anything inside the network perimeter. Zero-trust assumes the network is hostile: authenticate every service identity (mTLS), authorize every API call (RBAC or ABAC), encrypt all traffic in transit (TLS everywhere), and verify device posture for human users. In a Kubernetes context: (1) network policies restrict pod-to-pod communication to explicitly allowed pairs; (2) service mesh (Istio) enforces mTLS and authorization policies between services; (3) RBAC controls access to Kubernetes API resources; (4) pod security standards prevent privilege escalation.
SPIFFE (Secure Production Identity Framework For Everyone) provides workload identity in zero-trust environments. Each workload gets a SPIFFE Verifiable Identity Document (SVID) — a short-lived X.509 certificate identifying the workload's service account and namespace. SPIRE (the SPIFFE Runtime Environment) is the reference implementation. mTLS uses SVIDs for mutual authentication: service A presents its SVID to service B, which verifies it against the SPIRE trust bundle. Certificates rotate automatically (every hour by default), eliminating the long-lived credentials problem. The network policy model (deny-all default, allow-list specific pod-to-pod flows) is the technical enforcement mechanism — without it, a compromised pod can reach any other pod on the cluster.
I implement zero-trust with: (1) Istio service mesh for mTLS between all services with SPIFFE/SPIRE workload identity; (2) Istio AuthorizationPolicy for service-to-service RBAC (only the order service can call the payment service); (3) OPA/Gatekeeper for Kubernetes admission control; (4) network policies with default-deny ingress/egress. External users authenticate via OAuth2/OIDC at the API gateway; internal service calls use mTLS certificates, no API keys or passwords.
Treating VPN as zero-trust. A VPN moves the trust boundary from the office network to the VPN endpoint — it is still perimeter-based security, not zero-trust. Zero-trust authenticates and authorizes every individual request regardless of network origin.