Why Kubernetes Ingress Needs an Identity Layer

Kubernetes ingress controllers are excellent at one thing: moving encrypted traffic to the right service. But encryption alone does not equal security.

TLS ensures confidentiality in transit, but it does nothing to answer more important questions:

• Who is making this request?

• Are they still authorized?

• What policy applies right now?

As Kubernetes platforms scale and diversify, these questions become impossible to ignore.

The Limits of Perimeter Security

Ingress controllers assume that access control has already happened. Historically, this was handled by network boundaries: VPNs, corporate networks, and IP allowlists. Once inside the perimeter, services trusted incoming traffic.

This model breaks down in modern environments:

• Teams are distributed

• Contractors and partners need access

• Devices are untrusted

• Workloads are dynamic

Perimeter-based trust creates overly broad access and increases the impact of compromised credentials.

Identity as the New Control Plane

An identity layer introduces a fundamentally different model. Instead of trusting the network, systems trust verified identity and explicit policy.

In this model:

• Authentication happens at the edge

• Authorization is evaluated per request

• Policies reference identity attributes, not network location

Ingress without identity is blind to these dimensions. It cannot reason about group membership, role changes, or contextual signals.

Continuous Authorization Matters

Many systems authenticate users once and assume that authorization remains valid indefinitely. This assumption is increasingly dangerous.

Continuous authorization allows access to be revoked immediately when:

• A user changes roles

• A contractor’s engagement ends

• A device falls out of compliance

Identity-aware access proxies enforce this model by evaluating policy every time a request is made.

Practical Implications for Kubernetes

Adding an identity layer in front of Kubernetes services enables:

• Uniform access control across all internal tools

• Centralized policy management

• Elimination of app-specific auth integrations

• Strong audit trails tied to real identities

Ingress remains valuable for routing and load balancing, but identity-aware access completes the picture.

Here’s how Pomerium delivers identity-aware access control for Kubernetes. Whether you’re using user impersonation or a Pomerium JWT the Structured Authentication Configuration available in version 1.30+ of Kubernetes, both allow you to add per request authentication and authorization to your Kubernetes workloads.