Kubernetes ingress and identity layers: are your controls keeping up?

TL;DR: Kubernetes ingress controllers move encrypted traffic, but they do not answer who is requesting access, whether authorization still holds, or which policy applies per request, according to Pomerium. That gap makes perimeter-based trust too broad for distributed teams, contractors, and dynamic workloads, and turns identity-aware access into the missing control plane.

NHIMG editorial — based on content published by Pomerium: Why Kubernetes ingress needs an identity layer

Questions worth separating out

Q: How should security teams control Kubernetes access when ingress is already in place?

A: Treat ingress as a traffic path, not an authorization boundary.

Q: Why do perimeter-based trust models break down in Kubernetes environments?

A: Perimeter trust breaks down because Kubernetes access is no longer limited to stable internal users on managed networks.

Q: How do teams know if continuous authorisation is actually working?

A: Look for immediate access changes when roles change, engagements end, or device compliance fails.

Practitioner guidance

• Move authorisation to request time Evaluate each Kubernetes request against current identity, role, and policy state rather than assuming that edge authentication is sufficient for the whole session.
• Separate routing from trust decisions Keep ingress focused on transport and routing, then enforce access control in an identity-aware layer that can inspect subject context before the service receives the request.
• Remove network location as a trust signal Replace IP allowlists and perimeter assumptions with policy inputs based on verified identity attributes, group membership, and operational context.

What's in the full article

Pomerium's full blog post covers the operational detail this analysis intentionally leaves for the source:

• How user impersonation and Kubernetes JWT-based authentication can be configured for per-request control
• The version 1.30+ Kubernetes Structured Authentication Configuration path for integrating identity-aware access
• Specific examples of how Pomerium applies authentication and authorisation at the edge for Kubernetes workloads
• The implementation detail behind app-specific integrations that reduce the need for separate auth logic in each service

👉 Read Pomerium's analysis of why Kubernetes ingress needs an identity layer →

Kubernetes ingress and identity layers: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →