Authentication Delegation: Trusting the Proxy

The Security Challenge

When the main API server proxies a request to your Extension API Server, your extension receives an HTTP request from the API server — not directly from the user. This creates a security question: how does your extension know who the original user was, and how does it verify that the request actually came from the trusted API server (and not from a rogue pod that learned your service's address)?

Kubernetes solves this with a three-part mechanism called delegated authentication and authorization.

Part 1: Request Header Injection

The main API server strips the original user's credentials (bearer token, client cert) and replaces them with HTTP headers — an X-Remote-User header naming the user, one or more X-Remote-Group headers naming their group memberships, and X-Remote-Extra-* headers for any additional scopes. Your Extension API Server reads these headers to know who the user is.

Part 2: Mutual TLS (mTLS) for Header Trust

Headers are trivially forgeable. Any pod could send a request to your extension with X-Remote-User: admin. To prevent this, the main API server presents a client TLS certificate when connecting to your extension. Your extension must verify this certificate against a known CA (the requestheader-client-ca-file configured on the API server, available in the extension-apiserver-authentication ConfigMap in kube-system).

Only if the client certificate is valid does your extension trust the injected headers. This is the mTLS handshake that proves the proxy is legitimate.

Part 3: SubjectAccessReview for Authorization

Your extension doesn't have access to the cluster's RBAC database. To check whether Alice is allowed to perform a specific action, your extension sends a SubjectAccessReview request back to the main API server — naming the user, their groups, and the specific resource attributes being checked (namespace, verb, resource, and API group).

The main API server evaluates RBAC and returns allowed: true or allowed: false. Your extension acts on that answer.

Why this design matters: Your Extension API Server never needs to store user credentials, manage RBAC rules, or implement its own authentication system. It inherits the full security model of the cluster. This means that any RBAC rules you write for your custom API group are enforced by the main API server's RBAC engine — the same engine that protects core resources like Pods and Secrets.