Allow extension API server to read requestheader-client-ca from extension-apiserver-authentication ConfigMap
Closed this issue · 7 comments
Is this a BUG REPORT or FEATURE REQUEST?:
/kind feature
What happened:
When I start the core API server with requestheader-client-ca-file, it populates the extension-apiserver-authentication ConfigMap in kube-system namespace with the requestheader CA. This allows the extension API server to dynamically discover the CA and use it for validating the client certificate of aggregator layer. See here for documentation
However, if the core API server doesn't use certificate based authentication for it's clients i.e. client-ca-file flag isn't set in core API server then the extension API server fails to start with error message
Error: cluster doesn't provide client-ca-file
I believe this is coming from bootstrap code in extension API server here.
What you expected to happen:
Extension API server should be able to start and not require that both client-ca and requestheader-ca be present in the extension-apiserver-authentication ConfigMap. This allows Kubernetes clusters which don't use certificate based authentication for core API server to be able to dynamically discover the requestheader-ca instead of having to mount it as a secret.
How to reproduce it (as minimally and precisely as possible):
- Create a Kubernetes cluster which uses non certificate based authentication for core API server like Webhook based authentication. Example: You can launch an Amazon EKS cluster which uses Webhook based authentication following steps outlined here.
- Setup aggregator layer by adding flags mentioned here. CA certificate and client certificate for aggregator layer can be generated using
kubeadm alpha phase certs front-proxy-caandkubeadm alpha phase certs front-proxy-client. - Deploy metrics server to cluster following steps in Deployment section of README here
- Get logs of metrics server pod and it should be failing with error message above
Anything else we need to know?:
It's possible there is a reason which is not evident to me as to why extension API server would require both client-ca-file and requestheader-client-ca-file to be present in the ConfigMap.
Environment:
- Kubernetes version (use
kubectl version): 1.10.3 - Cloud provider or hardware configuration: Amazon EKS
- OS (e.g. from /etc/os-release): Kubernetes control plane and nodes = Amazon Linux 2 (2017.12) LTS Release Candidate (4.14.42).
/sig api-machinery
@kubernetes/sig-apimachinery-feature-requests
/cc @DirectXMan12
@kubernetes/sig-api-machinery-feature-requests, since it looks like the at-mention didn't take
Thanks Jordan. This is something we are interested in contributing to and ask for being cherrypicked to patch releases of 1.10.x and 1.11.x. That conversation can wait once we have the PR out.
Quick update: I'm working on sending a PR for this issue by this week