Replacing ingress-nginx for secure Kubernetes access control

At a glance

What this is: This is a practitioner analysis of why ingress-nginx is no longer enough for internal Kubernetes access, and why identity-aware policy enforcement has become the governing model.

Why it matters: It matters because Kubernetes now hosts internal tools, admin paths, and shared platforms that span human, NHI, and automated access patterns, so IAM teams need controls that enforce identity and context rather than network location.

👉 Read Pomerium's analysis of replacing ingress-nginx for secure Kubernetes access

Context

Kubernetes access control is no longer just a routing problem. As clusters increasingly host internal dashboards, CI/CD systems, data tools, admin consoles, and large-scale AI workloads, the security question shifts from how traffic enters the cluster to how access is approved for each request. In that environment, ingress-nginx remains a traffic component, but it is not a governance control for identity-aware access.

The gap is most visible when internal services are reached by distributed employees, contractors, service accounts, and other non-human identities. That mix exposes the limits of perimeter trust and application-by-application authentication. For teams formalising Zero Trust in Kubernetes, the practical issue is not ingress itself, but the need to separate routing from authorization and keep access decisions policy-driven. The Ultimate Guide to NHIs provides broader context on why non-human access needs its own governance model.

Key questions

Q: How should teams govern internal Kubernetes access without relying on ingress-nginx alone?

A: Teams should keep ingress-nginx focused on traffic routing and move authorization to an identity-aware control point in front of internal services. That separates networking from governance, lets policy evaluate identity and context on every request, and avoids the inconsistency that comes from embedding auth logic inside each application or depending on VPN trust.

Q: Why do internal Kubernetes services need identity-based access control?

A: Internal services are often reached by a mix of employees, contractors, automation, and non-human identities, so network location no longer tells you enough about trust. Identity-based access control lets teams decide who or what can reach a service based on policy, claims, and context instead of assuming the cluster boundary is secure.

Q: What breaks when access policy is scattered across apps and ingress rules?

A: Policy fragmentation creates inconsistent decisions, brittle configuration, and duplicated security logic. Teams lose a single point of control, and access changes become harder to audit because the effective policy is spread across applications, annotations, and supporting services rather than enforced centrally.

Q: What is the difference between routing traffic and authorizing access in Kubernetes?

A: Routing sends a request to the right service, while authorization decides whether that request should be allowed in the first place. In a secure Kubernetes model, routing should be handled by ingress infrastructure and authorization should be handled by an identity-aware policy layer before the service is reached.

Technical breakdown

Why ingress-nginx is not an authorization layer

Ingress-nginx is fundamentally a Layer-7 traffic controller. It can terminate TLS, route requests, and apply some auth hooks, but its job ends at request forwarding. That means it does not own the full access decision, and teams often compensate with VPNs, app-level authentication, or sprawling ingress annotations. Those patterns create inconsistent enforcement because authorization logic becomes fragmented across services instead of centralized at the edge.

Practical implication: treat ingress-nginx as routing infrastructure, not as the control point for identity-based access decisions.

Identity-aware access at the edge in Kubernetes

An identity-aware proxy shifts enforcement to a policy layer in front of services. Rather than trusting network location, it checks identity, context, and policy before allowing access to internal applications. This is the operational expression of Zero Trust in Kubernetes: authentication is explicit, authorization is continuous, and access can be tied to claims, groups, and other contextual signals. The architectural value is that applications do not need to embed their own auth stack just to remain private.

Practical implication: centralize policy enforcement at the edge so application teams do not replicate authorization logic in each service.

Hybrid Kubernetes access architecture and blast radius

Many teams end up with a split model: ingress-nginx handles public traffic while an identity-aware proxy secures internal services. This separates traffic management from access control and reduces the blast radius of perimeter-style trust. It also fits mixed environments where human users, contractors, and non-human identities all need different policy treatment. The key technical point is not replacement for its own sake, but isolation of access semantics from network plumbing.

Practical implication: restrict internal services so only the identity-aware access layer can reach them, and keep public routing separate from private authorization.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Ingress controllers fail when teams confuse routing with governance: ingress-nginx can move packets, but it was never built to decide whether a request should be trusted. That assumption breaks as soon as internal Kubernetes services become shared workspaces for employees, contractors, and non-human identities. The implication is that identity governance must sit alongside traffic control, not inside it.

Network perimeter trust is the wrong model for internal Kubernetes access: VPN-based access and perimeter-style admission expand blast radius and make access too coarse for modern clusters. Once internal dashboards, admin consoles, and data tools are exposed to mixed populations, the old network boundary becomes a weak proxy for trust. Practitioners should read that as a structural governance failure, not a tuning issue.

Policy at the edge is now the meaningful control point for Kubernetes identity: when access is decided by identity and context before a service is reached, security teams can keep application logic unchanged while still enforcing centralized policy. That matters for NHI governance as much as for human access because the same services are increasingly reached by service accounts, automation, and external collaborators. The practical conclusion is to design for a single policy layer instead of a patchwork of per-app rules.

Identity blast radius is the right concept for internal platform access: as internal Kubernetes services multiply, every extra trust path increases the number of identities that can reach sensitive functions. This is not merely a Kubernetes design problem, it is an access governance problem spanning human users and non-human identities alike. The practitioner takeaway is to measure how far a single authenticated identity can move across internal tools, not just whether it can connect.

Zero Trust in Kubernetes only works when authorization is independent of location: the article reinforces a simple but often ignored premise, network position should not be the basis for trust. That premise fails in distributed teams, contractor access, and shared automation alike. Teams should treat identity-aware authorization as the control that makes Zero Trust operational rather than aspirational.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably see the identities that may be reaching internal Kubernetes services.
• That visibility gap is why teams should pair edge policy with lifecycle governance, as explained in Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Identity blast radius: Kubernetes access programmes now need to measure how far a single authenticated identity can move across internal services, not just whether traffic can reach a pod. That shift matters because network controls do not describe real privilege, especially when employees, contractors, and non-human identities share the same internal platform.

A split model for routing and authorization is becoming the practical baseline for secure internal platforms. Teams that leave access decisions in ingress annotations or application code will keep accumulating hidden policy paths, which makes audit, review, and revocation harder than the traffic problem they were meant to solve.

For identity teams, the signal is clear: if a service can be reached without a dedicated policy layer, the environment still relies on implicit trust. That is incompatible with Zero Trust and with any serious governance model for NHI or mixed-identity access.

For practitioners

• Separate routing from authorization Keep ingress-nginx for public traffic flow and place identity-aware policy enforcement in front of internal services so access decisions are not scattered across annotations, apps, and VPN rules.
• Restrict internal services to the policy layer only Ensure internal Kubernetes services are reachable only through the access proxy, so identity, context, and policy are evaluated before a request reaches a backend service.
• Replace app-by-app auth with centralized policy Remove duplicated authentication logic from individual services where possible and express access decisions once at the edge using claims, groups, and contextual policy.
• Map mixed identity populations to distinct policies Document which internal workloads are accessed by employees, contractors, and non-human identities, then apply different authorization rules instead of assuming one network path fits all.

Key takeaways

• Ingress-nginx is a routing component, not an authorization layer, so it cannot by itself govern internal Kubernetes access.
• The governance problem is not only technical sprawl, it is trust sprawl across humans, contractors, and non-human identities.
• Teams should move authorization to an identity-aware edge control and keep public routing separate from private access policy.

Key terms

• Identity-aware access proxy: A control point that authenticates a requester and evaluates policy before allowing access to an application or service. In Kubernetes, it sits in front of internal workloads and replaces implicit network trust with explicit identity and context checks.
• Ingress controller: A Kubernetes component that routes external traffic to internal services and can terminate TLS or apply limited auth hooks. It is useful for traffic management, but it is not a full authorization system and should not be treated as one.
• Identity blast radius: The amount of internal access a single identity can reach once authenticated. In mixed Kubernetes environments, this includes human users, contractors, service accounts, and automated systems, so the blast radius is defined by policy coverage, not just network reach.
• Zero Trust architecture: A security model that assumes location is not trust and requires each request to be authenticated, authorized, and contextually evaluated. For Kubernetes, that means access decisions must be independent of cluster perimeter or VPN presence.

Deepen your knowledge

Kubernetes identity-aware access and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are reworking access control for internal platforms, it is worth exploring.

This post draws on content published by Pomerium: Replacing ingress-nginx with a modern approach to secure Kubernetes access. Read the original.