OpsCanary
kubernetesnetworkingPractitioner

Migrating to ALB: Mastering oauth2-proxy in Kubernetes

5 min read AWS Containers BlogOct 6, 2026Reviewed for accuracy
Share
Practitioner — Hands-on experience recommended

Migrating from NGINX Ingress to AWS Application Load Balancer (ALB) is a common challenge in Kubernetes environments. One of the key issues you’ll face is how to manage authentication with oauth2-proxy. Unlike NGINX, ALB cannot perform subrequests, meaning that if you don’t adjust your setup, traffic will flow to your backend without authentication. This can lead to significant security vulnerabilities if not handled properly.

To effectively manage oauth2-proxy with ALB, you have two main solutions. The first is to keep oauth2-proxy in your architecture but switch it from auth-subrequest mode to reverse proxy mode. In this setup, all traffic goes directly to oauth2-proxy, which then handles authentication. You’ll need to configure parameters like --reverse-proxy=true to trust X-Forwarded headers from ALB, and --pass-authorization-header=true to send the authorization token to your upstream service. The second solution leverages ALB's built-in OIDC authentication action, which allows you to perform the full OpenID Connect flow directly through ALB. This eliminates the need for oauth2-proxy altogether in some cases.

In production, understanding these configurations is crucial. You’ll need to ensure that your Ingress resources are correctly annotated to use ALB features, like specifying the OIDC issuer and endpoints. For instance, using the alb.ingress.kubernetes.io/auth-type: oidc annotation is essential for enabling OIDC authentication. Remember, the NGINX Ingress Controller was retired in March 2026, so transitioning to ALB is not just a choice; it’s a necessity for future-proofing your applications.

Key takeaways

  • →Configure oauth2-proxy with `--reverse-proxy=true` to trust ALB headers.
  • →Use `--pass-authorization-header=true` to forward tokens to your backend.
  • →Leverage ALB's built-in OIDC authentication for a streamlined setup.
  • →Annotate your Ingress with OIDC parameters for proper authentication flow.
  • →Remember that NGINX Ingress Controller is retired; plan your migration accordingly.

Why it matters

Properly managing oauth2-proxy with ALB ensures secure authentication for your applications, preventing unauthorized access and potential data breaches.

Code examples

YAML
1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: my-app-alb
5  annotations:
6    alb.ingress.kubernetes.io/scheme: internal
7    alb.ingress.kubernetes.io/target-type: ip
8    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
9    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:REGION:ACCOUNT:certificate/CERT-ID
10    alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06
11    alb.ingress.kubernetes.io/healthcheck-path: /ping
12    alb.ingress.kubernetes.io/healthcheck-port: "4180"
13    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
14    alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=86400
15spec:
16  ingressClassName: alb
17  rules:
18    - host: app.example.com
19      http:
20        paths:
21          - path: /
22            pathType: Prefix
23            backend:
24              service:
25                name: oauth2-proxy    # ALL traffic goes to oauth2-proxy
26                port:
27                  number: 4180
YAML
1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: my-app
5  annotations:
6    alb.ingress.kubernetes.io/scheme: internal
7    alb.ingress.kubernetes.io/target-type: ip
8    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
9    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:REGION:ACCOUNT:certificate/CERT-ID
10    alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06
11
12    # OIDC Authentication
13    alb.ingress.kubernetes.io/auth-type: oidc
14    alb.ingress.kubernetes.io/auth-idp-oidc: |
15      {
16        "issuer": "https://your-idp.example.com/realms/your-realm",
17        "authorizationEndpoint": "https://your-idp.example.com/realms/your-realm/protocol/openid-connect/auth",
18        "tokenEndpoint": "https://your-idp.example.com/realms/your-realm/protocol/openid-connect/token",
19        "userInfoEndpoint": "https://your-idp.example.com/realms/your-realm/protocol/openid-connect/userinfo",
20        "secretName": "alb-oidc-secret"
21      }
22    alb.ingress.kubernetes.io/auth-scope: "openid email profile"
23    alb.ingress.kubernetes.io/auth-session-timeout: "86400"
24    alb.ingress.kubernetes.io/auth-on-unauthenticated-request: authenticate
25
26    # Health check
27    alb.ingress.kubernetes.io/healthcheck-path: /healthz
28    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
29spec:
30  ingressClassName: alb
31  rules:
32    - host: app.example.com
33      http:
34        paths:
35          - path: /
36            pathType: Prefix
37            backend:
38              service:
39                name: my-backend
40                port:
41                  number: 8080
Bash
kubectl create secret generic alb-oidc-secret \
  --from-literal=clientId=my-app \
  --from-literal=clientSecret=YOUR_CLIENT_SECRET

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →
Linux FoundationSponsor

Industry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.

Get CKA certified →

Get the daily digest

One email. 5 articles. Every morning.

No spam. Unsubscribe anytime.