Set up kube-oidc-proxy to enable OIDC authentication on managed Kubernetes clusters like GKE or EKS, even without direct API server access. Our Kubernetes support team is always here to help you.

kube-oidc-proxy: Secure OIDC Authentication for Managed Kubernetes Clusters

When using managed Kubernetes providers like GKE or EKS, you can’t directly modify the API server flags to enable OIDC authentication. That’s exactly where kube-oidc-proxy comes in. It acts as a reverse proxy that handles user authentication using OpenID Connect (OIDC), even when the underlying Kubernetes API server doesn’t support it directly.

This blog walks through exactly how it works, without fluff, without unnecessary jargon. Just straight facts and steps, so you can get it running with confidence.

What is kube-oidc-proxy?

This is a reverse proxy server that authenticates users via OIDC and forwards requests to the Kubernetes API server using impersonation headers. This is especially useful in managed Kubernetes environments where you can’t enable native OIDC support, such as when you install Kubernetes on Ubuntu 22.04 single node.

How kube-oidc-proxy Works

When working with managed providers, you typically can’t alter the API server’s configuration. Since that’s the case, you set up a reverse proxy in front of the Kubernetes API server to handle authentication instead.

Here’s exactly how it operates:

• The proxy sits inside the cluster and securely serves requests to the outside world.
• Once discovery with the OIDC provider is successful, it begins accepting user requests (see unexpected admission error in Kubernetes).
• It then authenticates the request by validating the OIDC token in the request header.
• If authentication fails, it returns a 401 Unauthorized error to the client.

It also checks for any impersonation headers sent by the client. Since it uses impersonation to interact with the API server, it rejects all user-sent impersonation headers with a 403 Forbidden.

The client will see this error in the terminal:

Error from server (Forbidden): Impersonation requests are disabled when using this proxy

Once the token is authenticated using the OIDC provider’s public keys, the proxy:

• Constructs impersonation headers using the Username claim from the token.
• Assigns any groups based on the configured group claim.
• Sends the original request (now containing impersonation headers) to the API server.
• Replaces the authentication on the request with its own, usually a Bearer token from a Kubernetes Service Account.
• That Service Account must have RBAC permissions to impersonate any user or group cluster-wide.

Performance and Scaling

Plus, it’s stateless, meaning it scales efficiently inside your cluster, even when handling scheduled jobs like Kubernetes CronJobs with resource limits.

[If needed, Our team is available 24/7 for additional assistance.]

Conclusion

If you’re working with GKE, EKS, or any Kubernetes setup where direct API server access is blocked, kube-oidc-proxy is your best option for secure, scalable OIDC authentication. It mimics Kubernetes’ native behavior closely, and its support for impersonation means you can enforce fine-grained RBAC across your cluster without giving up user-level authentication.