Replacing Ingress-NGINX: A Modern Approach to Secure Kubernetes Access

For years, NGINX Ingress has been the default answer to a simple question: How do I get traffic into my Kubernetes cluster? It excels at Layer-7 routing, TLS termination, and traffic shaping, and for many workloads it remains a solid choice. But as Kubernetes has moved beyond hosting public-facing services and into powering internal platforms, the limitations of traditional ingress have become increasingly apparent.

Today, Kubernetes clusters commonly host internal dashboards, CI/CD systems, data tools, admin consoles, developer platforms, and large scale LLM research workloads. These services are not meant for the public internet, yet they are frequently accessed by distributed employees, contractors, and automated systems. Typically, security has been an afterthought when configuring Kubernetes, however, with the expansion of Kubernetes use across dev teams, controlling access is now a primary concern.

Why Ingress-NGINX Falls Short for Internal Access

Ingress-NGINX is fundamentally network-centric. Its core responsibility ends once a request is routed to the correct service. While it supports basic authentication and external auth hooks, these mechanisms were never designed to serve as a comprehensive access control layer.

As a result, teams often end up with one of three patterns:

• Relying on VPNs to establish a trusted network perimeter

• Embedding authentication logic directly into each application

• Maintaining a fragile web of ingress annotations, auth services, and per-app configuration

Each approach introduces operational drag and security risk. VPNs expand blast radius and create coarse-grained access. Application-level auth leads to duplication and inconsistency. And complex ingress configurations become brittle as environments scale.

The Shift from Network Trust to Identity Trust

Modern infrastructure has moved away from implicit trust based on network location. Instead, access decisions are increasingly driven by identity, context, and policy. This is the core principle behind Zero Trust architectures.

In a Zero Trust model:

• Every request is authenticated and authorized

• Authorization is continuously evaluated

• Access is granted based on identity and context, not just IP address or network topology

Traditional ingress controllers were never built to enforce this model. They assume trust has already been established elsewhere.

Introducing Identity-Aware Access at the Edge

An identity-aware access proxy like Pomerium changes the role of ingress entirely. Rather than acting as a simple traffic router, it becomes a policy enforcement point in front of your services.

With Pomerium:

• Users authenticate via your existing identity provider (Okta, Azure AD, Google Workspace, etc.)

• Policies define who can access what, using many of the typical features from RBAC models like identity claims and groups, plus additional sources of 3rd party context

• Applications remain unchanged

• Every request is logged and auditable

This approach allows teams to replace VPN-based access and per-app authentication with a centralized, consistent model for all workloads, not just ones in Kubernetes.

A New Access Architecture for Kubernetes

In practice, many teams adopt a hybrid approach:

• Ingress-NGINX continues to handle public traffic

• Pomerium secures internal services

• Access to internal services is restricted to Pomerium only

This separation of concerns simplifies both routing and security. Ingress handles traffic flow; Pomerium handles access control.

The Time to Replace Ingress-NGINX is Now

The time to replace Ingress-NGINX is now. With the upcoming end-of-life (EoL), Pomerium offers Ingress-NGINX users a supported, open source alternative that requires you to change only a few lines of your existing policy language to be compatible with Pomerium:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
+ annotations:
+	ingress.pomerium.io/policy:
+    - allow:
+		any: true
spec:
-  ingressClassName: nginx
+  ingressClassName: pomerium
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls-cert

For users who prefer a managed GUI instead of open source, Pomerium Zero is also available for free for homelab users.