Separate aggregation-proxy and ordinary-client CAs in Kubernetes

Bottom line: Treat the aggregation proxy and ordinary API clients as separate certificate-trust roles. Require a review of both authentication paths before approving CA reuse or a proxy identity change.

Source fact: documented behavior

The Configure the Aggregation Layer documentation is the primary reference.

For an aggregation proxy, the source requires a certificate signed by the CA configured in --requestheader-client-ca-file, with its common name allowed by --requestheader-allowed-names. Kubernetes evaluates the request-header CA before the ordinary --client-ca-file CA; reusing one CA can send legitimate ordinary clients into the proxy common-name check and reject them. The guide therefore calls for different CA certificates for these two roles.

What the source does not establish

This article addresses two client-authentication paths within Kubernetes aggregation. It is not a website server-certificate procedure or a general CA-rotation playbook. It does not authorize relaxing proxy names, replacing a cluster CA or assuming that an existing installation uses these exact managed settings.

Applicability questions

• Which authority signs the aggregation proxy’s client certificate?
• Which authority validates ordinary API clients?
• What exact proxy common names are intended?
• Who owns the control-plane trust configuration and recovery procedure?

DSE recommendation: map the two trust paths explicitly

DSE recommends a two-column trust diagram before changing aggregation authentication. Put the proxy client identity, issuing CA and allowed names in one column. Put the ordinary-client trust population in the other. Have the platform owner identify the managed configuration responsible for each value.

Compare certificate issuer information with that diagram using approved certificate inspection. Retain safe fingerprints and identity fields rather than private keys or reusable credentials. Treat a shared authority as a configuration finding that needs an explicit remediation plan; do not broaden the allowed-name list simply to restore an unrelated client.

Identify representative ordinary clients and an approved extension API before scheduling a trust change. Assign separate success criteria for each path. Include recovery access that does not depend on the exact configuration being changed, and have the responsible administrator approve the rollback procedure.

Keep issuance, configuration distribution and client acceptance as separate checkpoints. If the installation’s distribution manages these settings indirectly, follow its supported mechanism rather than editing generated files. Resolve an unexplained mismatch between the intended roles and observed configuration before approving a wider rollout.

Verification and evidence

Proposed verification: reproduce the intended separated trust arrangement in an isolated representative cluster. Use disposable proxy and ordinary-client identities, recording their issuers and approved names without key material. Predict which trust path should apply to each identity.

Exercise an approved extension request and an ordinary API request independently. Include an unapproved proxy-name case under the controlled test plan. Preserve actual authentication outcomes and the relevant sanitized configuration, without converting a failed request into permission to widen trust. Acceptance should explain both paths; one successful API call is insufficient evidence for the other.

Official references

• Configure the Aggregation Layer — Kubernetes.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.