Extensions apiserver allocation endpoint reachable without Kubernetes RBAC

[adilburaksen]

Summary

The Agones extensions apiserver (agones-controller-service:443/apis/allocation.agones.dev/v1/...) serves as a Kubernetes aggregated APIService. When Kubernetes routes allocation requests through the API server aggregator, the aggregator enforces authn/authz normally. However, the same service port is directly reachable within the cluster as a standard Service endpoint.

The extensions HTTPS server (pkg/util/https/server.go) configures TLS with GetCertificate only — no ClientAuth, no RequestHeader CA verification, no bearer-token authentication, and no SubjectAccessReview before dispatching to resource handlers. pkg/util/apiserver/apiserver.go routes /apis/<groupVersion>/namespaces/ directly to CRDHandler delegates without any authorization middleware.

As a result, any in-cluster workload that can reach agones-controller-service on port 443 can POST a GameServerAllocation directly, bypassing Kubernetes RBAC for the aggregated resource.

Affected files

• pkg/util/https/server.go — TLS config lacks ClientAuth / RequestHeader CA
• pkg/util/apiserver/apiserver.go — no auth middleware before resource dispatch
• cmd/extensions/main.go — extension server shares the webhook mux without auth

Expected fix

Implement Kubernetes aggregation layer authentication on the extension HTTPS server:

• Load extension-apiserver-authentication ConfigMap from kube-system
• Configure ClientAuth: VerifyClientCertIfGiven with the RequestHeader CA
• Verify the proxy client certificate CN against requestheader-allowed-names

The controller service account already has system:auth-delegator and extension-apiserver-authentication-reader bindings, which suggests this authentication was intended but not yet implemented.

Note

This issue was first surfaced in PR #4557 (closed for code quality). This issue is to discuss the right implementation approach before a fix PR is opened.

[markmandel]

This doesn't seem unreasonable to add - also super nice to actually see that the apiserver layer is actually documented now! (shakes old man fist at cloud 👴🏻 ✊🏻 ☁️ 😁 , back in my day we had to work it out for ourselves)

I don't think this would affect backward compatibility or performance, but just want to keep that in mind when implementing a fix.

I'm also assuming there is a standard library in go for doing this?

[adilburaksen]

Yes, there's a standard library for this. Most extension apiservers built on k8s.io/apiserver get RequestHeader auth wired up automatically through RecommendedOptions — the relevant flags are --requestheader-client-ca-file, --requestheader-allowed-names, and --requestheader-username-headers.

If the allocation apiserver is using genericapiserver under the hood it might just be a matter of enabling Authentication.RequestHeader in the server config rather than building it from scratch. Happy to dig into the implementation if that'd be helpful.

[markmandel]

Our APIServer implementation is here: https://github.com/agones-dev/agones/tree/main/pkg/util/apiserver it's super lightweight... because it was written well before there were good tools for this stuff 😁

[adilburaksen]

Thanks for pointing to the implementation — that helps a lot.

Looking at pkg/util/apiserver/apiserver.go, the fix is straightforward to scope correctly since AddAPIResource already centralises handler registration. The plan:

1. TLS layer — add ClientAuth: tls.RequestClientCert to the https.Server TLS config so client certificates are forwarded to the HTTP layer (no breakage to existing webhook paths that don't send a cert).

2. Middleware in AddAPIResource — wrap each CRDHandler with a check that:

   • rejects requests with no TLS client certificate (HTTP 401)
   • verifies the certificate against the requestheader client CA (rejects if not signed by it)
   • passes verified requests through as normal

3. CA loading — read requestheader-client-ca-file from the kube-system/extension-apiserver-authentication ConfigMap at startup (the standard place Kubernetes publishes it) and pass the parsed *x509.CertPool into NewAPIServer.

This keeps the existing lightweight design intact — no dependency on k8s.io/apiserver genericapiserver, just a small middleware and a one-line TLS config change. Webhook handlers registered directly on the mux are unaffected.

Happy to write a PR for this if that's useful.

[markmandel]

@nrwiersma we chatted on slack, and you pointed to - https://github.com/kubernetes/apiserver/blob/master/pkg/authentication/request/x509/x509.go#L138

@adilburaksen - any reason not to use that?

[adilburaksen]

No reason not to — that's exactly the right approach. Using k8s.io/apiserver/pkg/authentication/request/x509 avoids re-implementing the TLS verification logic ourselves and stays consistent with how Kubernetes expects aggregated API servers to authenticate proxy requests.

The plan:

1. Load requestheader-client-ca-file from the extension-apiserver-authentication ConfigMap in kube-system
2. Build a x509.Authenticator with that CA as VerifyOptions.Roots
3. Configure TLS with ClientAuth: tls.RequestClientCert so the proxy cert is sent
4. Wrap AddAPIResource handlers with a middleware that calls AuthenticateRequest and returns 401 if the cert doesn't verify

I'll open a PR with this approach.