Pomerium

Employees may need access to internal web applications without joining an entire private network. Pomerium sits in front of those applications, uses an identity provider to establish who the visitor is and evaluates rules for the requested route. That makes it useful for applying consistent sign-in and access policies across services. Its Kubernetes controller also manages routing, so deployment choices must define both which traffic it owns and which identities are allowed to reach each application.

Current guidance

Current official Kubernetes documentation describes a controller that builds routes from Ingress resources, selects a matching ingressClassName and requires HTTPS. This is a useful current installation model, but it is not evidence that an old stable/pomerium release can be upgraded by changing only its chart repository.

Decide whether Pomerium will own the external ingress path or sit within an existing access architecture. Inventory identity-provider claims, allowed users/groups, session behavior, upstream identity headers and mutual TLS requirements. Policies attached to routes need the same review as application authorization; an authenticated user should not automatically be allowed to reach every protected service.

Translate configuration deliberately into the selected controller’s global settings and per-route annotations. Test accepted and denied identities, overlapping host/path routes, logout, expired sessions, WebSockets and upstream TLS against representative applications. Restrict namespace and ingress-class ownership so two controllers do not compete. Keep the previous endpoint available until authorization behavior, not just successful login, matches the migration plan. No access-policy migration was executed here.