extensions: authenticate allocation endpoint with requestheader client CA

[adilburaksen]

Summary

This PR fixes an authorization bypass in Agones' extension API server where any in-cluster workload could call the allocation endpoint directly, bypassing Kubernetes RBAC entirely.

Problem

The Agones extension API server (port 8082) serves /apis/allocation.agones.dev/v1/namespaces/…/gameserverallocations via its own HTTP mux. When a client calls this endpoint through the Kubernetes aggregation layer, kube-apiserver proxies the request and includes a requestheader client certificate signed by the requestheader CA (from kube-system/extension-apiserver-authentication).

Previously, the server did not verify that certificate. Any pod with network access to port 8082 could send a raw HTTP request and receive a valid response — no Kubernetes ServiceAccount token, no RBAC check, nothing.

Fix

Three files changed:

pkg/util/https/server.go

• Set ClientAuth: tls.RequestClientCert on the TLS config.
• This asks callers to present a certificate but does not require one, so webhook callers that do not present a cert are unaffected.
• The cert becomes available in r.TLS.PeerCertificates for the auth middleware.

pkg/util/apiserver/apiserver.go

• Added SetRequestHeaderCA(*x509.CertPool) — called at startup to supply the CA.
• Added authenticatedHandler — wraps any ErrorHandlerFunc to verify the first peer certificate against the CA pool with ExtKeyUsageClientAuth. Mirrors the logic in k8s.io/apiserver/pkg/authentication/request/x509.
• If no CA is configured (unit tests, local dev), the handler passes through unchanged.
• Discovery (/apis/allocation.agones.dev/v1) and OpenAPI handlers are left unauthenticated — they carry no sensitive data and are called by tools that do not present certs.
• Only the /apis/…/namespaces/ resource handler (i.e. the allocation endpoint) requires the cert.

cmd/extensions/main.go

• Added loadRequestHeaderCA — reads kube-system/extension-apiserver-authentication ConfigMap, parses requestheader-client-ca-file PEM, returns an *x509.CertPool.
• Wired in after NewAPIServer; if the ConfigMap is absent or empty (e.g. clusters that don't use the aggregation layer), the server starts with a warning and no auth enforcement, preserving backward compatibility.

Testing

Existing unit tests pass (go test ./pkg/util/apiserver/...). The authenticatedHandler nil-CA path ensures existing tests continue to work without TLS setup.

Integration / e2e: the TLS RequestClientCert flag is transparent to callers that don't present a cert (webhook callers), and kube-apiserver always presents the requestheader cert when proxying aggregation-layer requests.

References

• Kubernetes requestheader authentication: https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/
• Upstream x509 authenticator: https://github.com/kubernetes/apiserver/blob/master/pkg/authentication/request/x509/x509.go#L138
• extension-apiserver-authentication ConfigMap: https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/#contacting-the-extension-apiserver

[markmandel]

/gcbrun

[agones-bot]

Build Failed 😭

Build Id: c818caef-47eb-44ed-90a9-b5a07b23a94f

Status: FAILURE

• Cloud Build view
• Cloud Build log download

To get permission to view the Cloud Build view, join the agones-discuss Google Group.

[adilburaksen]

These failures appear to be pre-existing infrastructure issues unrelated to this PR's changes:

Step #26 (upgrade-test): The build fails with code=404, Not found: projects/agones-images/locations/us-east1/clusters/standard-upgrade-test-cluster-1-31. The GKE cluster does not exist — this is an infrastructure issue.

Step #28 (e2e-test): Of the four clusters tested, three pass and one fails:

• generic-1.33: SUCCESS
• gke-autopilot-1.34: SUCCESS
• generic-1.35: SUCCESS
• gke-autopilot-1.35: FAILURE

Since generic-1.35 and gke-autopilot-1.35 run the same Kubernetes version and our change (adding RequestClientCert to the TLS config and the authenticatedHandler middleware) would affect all clusters equally, the gke-autopilot-1.35-specific failure looks like a pre-existing flaky test or autopilot-specific infrastructure issue rather than a regression introduced here.

Happy to re-trigger (/gcbrun) if that would be helpful to confirm.

[markmandel]

/gcbrun

It's a flake we see on autopilot sometimes.

VERBOSE: time="2026-05-23 05:04:19.565" level=info msg="2026/05/23 05:04:18 Starting TCP server, listening on port 7654" options="&PodLogOptions{Container:game-server,Follow:false,Previous:false,SinceSeconds:nil,SinceTime:<nil>,Timestamps:false,TailLines:nil,LimitBytes:nil,InsecureSkipTLSVerifyBackend:false,Stream:nil,}" test=TestGameServerTcpProtocol
VERBOSE: time="2026-05-23 05:04:19.565" level=info msg="2026/05/23 05:04:18 Marking this server as ready" options="&PodLogOptions{Container:game-server,Follow:false,Previous:false,SinceSeconds:nil,SinceTime:<nil>,Timestamps:false,TailLines:nil,LimitBytes:nil,InsecureSkipTLSVerifyBackend:false,Stream:nil,}" test=TestGameServerTcpProtocol
VERBOSE: time="2026-05-23 05:04:19.565" level=info msg="---End of container logs---" options="&PodLogOptions{Container:game-server,Follow:false,Previous:false,SinceSeconds:nil,SinceTime:<nil>,Timestamps:false,TailLines:nil,LimitBytes:nil,InsecureSkipTLSVerifyBackend:false,Stream:nil,}" test=TestGameServerTcpProtocol
VERBOSE: time="2026-05-23 05:04:19.623" level=warning msg="Error opening log stream for container" error="previous terminated container \"game-server\" in pod \"game-serverxzq28\" not found" options="&PodLogOptions{Container:game-server,Follow:false,Previous:true,SinceSeconds:nil,SinceTime:<nil>,Timestamps:false,TailLines:nil,LimitBytes:nil,InsecureSkipTLSVerifyBackend:false,Stream:nil,}" test=TestGameServerTcpProtocol
VERBOSE:     gameserver_test.go:1068: 
VERBOSE:         	Error Trace:	/go/src/agones.dev/agones/test/e2e/gameserver_test.go:1068
VERBOSE:         	Error:      	Received unexpected error:
VERBOSE:         	            	dial tcp 35.227.71.13:7855: connect: connection refused
VERBOSE:         	Test:       	TestGameServerTcpProtocol
VERBOSE: --- FAIL: TestGameServerTcpProtocol (2.64s)

Tempted to add a retry in there for CI, but it shouldn't be needed -- but I digress.

[markmandel]

Also noting, you will need to sign your commits per DCO.

[agones-bot]

Build Succeeded 🥳

Build Id: 5c38641c-8e08-4493-bc28-2d26dea689a5

The following development artifacts have been built, and will exist for the next 30 days:

• image: us-docker.pkg.dev/agones-images/ci/agones-controller:1.58.0-dev-08a3dfe
• image: us-docker.pkg.dev/agones-images/ci/agones-extensions:1.58.0-dev-08a3dfe
• image: us-docker.pkg.dev/agones-images/ci/agones-sdk:1.58.0-dev-08a3dfe-linux
• image: us-docker.pkg.dev/agones-images/ci/agones-ping:1.58.0-dev-08a3dfe
• image: us-docker.pkg.dev/agones-images/ci/agones-allocator:1.58.0-dev-08a3dfe
• image: us-docker.pkg.dev/agones-images/ci/agones-processor:1.58.0-dev-08a3dfe
• Linux C++ SDK (build): agonessdk-1.58.0-dev-08a3dfe-linux-arch_64.tar.gz
• SDK Server: agonessdk-server-1.58.0-dev-08a3dfe.zip

A preview of the website (the last 30 builds are retained):

• https://08a3dfe-dot-preview-dot-agones-images.appspot.com/

To install this version:

git fetch https://github.com/googleforgames/agones.git pull/4582/head:pr_4582 && git checkout pr_4582
helm install agones ./install/helm/agones --namespace agones-system --set agones.image.registry=us-docker.pkg.dev/agones-images/ci --set agones.image.tag=1.58.0-dev-08a3dfe