Tutorial rebuilds OAuth2 Proxy authentication on Gateway API and Traefik as ingress-nginx retires

What the guide covers

A tutorial published on dev.to rebuilds a browser-based authentication stack for internal Kubernetes services, moving it off ingress-nginx annotations and onto the Kubernetes Gateway API. The author writes that ingress-nginx is being retired and that new traffic-management work belongs on Gateway API, which is why an earlier version of the same guide, built around ingress-nginx, needed a rewrite.

The resulting setup exposes three HTTPS hostnames under one wildcard domain: the Pocket ID identity-provider UI, the OAuth2 Proxy endpoints, and a protected demo service. Keeping everything under a single parent domain lets OAuth2 Proxy issue a narrowly scoped shared session cookie, and the author warns against widening that cookie domain when unrelated applications share the parent.

The gap Gateway API leaves

Gateway API standardizes the routing resources Gateway and HTTPRoute, but as the guide points out, it does not standardize browser-based OIDC login or an external-auth check. The author fills that gap with Traefik's Middleware custom resources. The consequence: with Envoy Gateway, Kong, Cilium or another implementation, the standard Gateway and HTTPRoute objects carry over unchanged, but the authentication adapter has to be swapped for that implementation's equivalent.

The behavioral difference also matters. In the new flow, Traefik consults OAuth2 Proxy's /oauth2/auth endpoint, which answers 202 when a session is valid and 401 when it is not; Traefik's Errors middleware then turns that 401 into the browser redirect to the sign-in page. The author calls this separate redirect step the most important difference from the old annotation-driven approach.

From CRDs to a running gateway

The walkthrough was verified on a local K3s cluster, though it relies on standard kubectl and Helm commands. Because Gateway API ships as an add-on rather than a cluster built-in, the first step installs the standard-channel CRDs — Gateway, GatewayClass and HTTPRoute — which the author applies from the v1.6.1 release before installing any implementation.

Traefik then goes in via its Helm chart with the Kubernetes Gateway provider enabled and its Service set to type LoadBalancer. The guide is explicit about the separation of concerns: the Gateway resource is routing configuration only, and it is Traefik's Service that actually accepts traffic. On managed clusters that means a cloud load balancer; on bare metal the author points to MetalLB or an existing external load balancer.

TLS is handled by cert-manager, which the guide assumes already exists with a working ClusterIssuer. A wildcard certificate is attached to an HTTPS listener that terminates TLS on port 443, and readers are told not to continue until the Certificate reports Ready=True and the Gateway reports Programmed=True.

OIDC provider and client setup

For identity the guide uses Pocket ID, chosen because passkeys keep a small personal or team deployment simple; the author notes any other OIDC provider would work and only OAuth2 Proxy's provider settings would change. Pocket ID is installed from the anza-labs Helm chart and exposed through a plain HTTPRoute rather than an Ingress.

After the initial setup, the author creates a user with a passkey and a verified email address, a developers group, and an OIDC client whose redirect URL points at the OAuth2 Proxy callback. Two requirements are called out: Pocket ID must send the groups claim, because OAuth2 Proxy admits only members of the developers group, and the email must be verified, since OAuth2 Proxy rejects Pocket ID's ID token otherwise. The published text ends as the author begins the OAuth2 Proxy installation with a Kubernetes Secret holding the client credentials.

Why it matters

The retirement of ingress-nginx turns every annotation-based setup built on it into a migration project, and authentication is one of the harder cases because it leans on controller-specific behavior. This guide sketches the shape of that migration: routing moves to portable, standardized Gateway and HTTPRoute objects, while anything the standard does not cover — here, the OIDC login redirect — stays implementation-specific and must be solved again for each controller. Teams planning a move can budget accordingly: the routes port over, the middleware glue does not. The walkthrough is also a useful reminder that Gateway API is not installed by default, and that DNS, certificates and load-balancer exposure remain prerequisites whichever implementation you pick.