Zero trust Kubernetes: Context over credentials

How identity-aware proxies eliminate credential headaches.

Frank Abagnale bamboozled his way through the 1960s by pretending to be a pilot. He got a uniform from a dry cleaner, created fake credentials, and rode 250 flights for free in cockpit jump seats. In this presentation at All Things Open, Nick Taylor, Developer Advocate at Pomerium, shares why Frank’s attack worked: Once identity was assumed through the uniform, no further verification occurred. Once you’re inside perimeter-based security, you’re generally trusted. And it’s still happening today with VPN breaches making headlines.

Modern challenges expose perimeter security’s weaknesses. Remote work means VPNs drain mobile batteries and drop sessions. Contractors need access to specific resources, not broad network access, but VPNs make limiting scope difficult. Revoking access when contractors leave often fails as cached sessions persist. Cloud-native workloads like Kubernetes make perimeters less well-defined. The industry is moving toward identity and context-based security, accelerated by Google’s complete security overhaul after a massive breach in the 2010s documented in their BeyondCorp papers.

Zero trust principles address these gaps: Never trust, always verify. No implicit trust based on network location. Assume bad actors exist in your network and minimize blast radius. Think airport security with multiple checkpoints verifying boarding passes, passports, and scanning bags. There’s no implicit trust at any step, just continuous verification.

Read more: Stop opening firewall ports and start using identity

The core components include an identity provider (Google, Microsoft Entra, Okta, or Keycloak) to verify who you are, a policy engine defining context-based rules (time restrictions, role requirements, route permissions), and a reverse proxy operating at layer 7 that validates every request. Together these create an identity-aware proxy at your network’s edge, providing micro-segmentation where you only access the specific resource you need.

Nick applies this to Kubernetes at three levels. An identity-aware ingress controller creates routes securing internal services. The Kubernetes API gets protected so kubectl commands and tools like K9s require authentication. SSH access to nodes flows through the identity-aware proxy using short-lived certificates without managing keys. Watch Nick perform live demos of SSH with device code verification, securing the Kubernetes API for kubectl access, and real-time policy enforcement showing immediate access revocation when permissions change.

Key takeaways

• Perimeter security fails because once inside the VPN, you’re trusted. Zero trust verifies identity and context at every request, preventing lateral movement.
• Identity-aware proxies provide micro-segmentation, audit logging, and policy-based access control without custom authentication code in applications.
• Kubernetes security spans ingress controllers, API access, and node SSH, all unified through identity verification and context-aware policies.

Security becomes a shared responsibility with developers implementing patterns, security teams managing central policies, and users experiencing seamless access through existing identity providers.

More from We Love Open Source

• OpenClaw: Anatomy of a viral open source AI agent
• How to secure agentic AI with Agent Identity Protocol (AIP)
• How to balance open source learning and AI productivity hacks
• The AI slop problem threatening open source maintainers
• Stop opening firewall ports and start using identity