Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When I start the core API server with , it populates the ConfigMap in 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 for documentation However, if the core API server doesn't use certificate based authentication for it's clients i.e. flag isn't set in core API server then the extension API server fails to start with error message I believe this is coming from bootstrap code in extension API server . What you expected to happen: Extension API server should be able to start and not require that both and be present in the 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 . Setup aggregator layer by adding flags mentioned . CA certificate and client certificate for aggregator layer can be generated using and . Deploy metrics server to cluster following steps in Deployment section of README 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 ): 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 /cc
since it looks like the at-mention didn't take
/sig auth /assign
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
- Now that this is merged, can we open up the possibility of cherry picking to 1.10.x and 1.11.X please?
sure, opened , ,

Discussion:
clientCA, err := s.getClientCA() if err != nil { <del> return err </del> <ins> if _, ignorable := err.(ignorableError); !ignorable { return err } else { glog.Warning(err) } </ins> } if err = c.ApplyClientCert(clientCA.ClientCA, servingInfo); err != nil { return fmt.Errorf("unable to load client CA file: %v", err)

clientCA, err := s.getClientCA() if err != nil { <del> return authenticatorfactory.DelegatingAuthenticatorConfig{}, err </del> <ins> if _, ignorable := err.(ignorableError); !ignorable { return authenticatorfactory.DelegatingAuthenticatorConfig{}, err } else { glog.Warning(err) } </ins> } requestHeader, err := s.getRequestHeader() if err != nil {

return nil, err } if incluster == nil { <del> return nil, fmt.Errorf("cluster doesn't provide client-ca-file") </del> <ins> return &s.ClientCert, ignorableError{fmt.Errorf("cluster doesn't provide client-ca-file in configmap/%s in %s, so client certificate authentication to extension api-server won't work.", authenticationConfigMapName, authenticationConfigMapNamespace)} </ins> } return incluster, nil }

return client.TokenReviews(), nil } <ins> type ignorableError struct{ error } </ins>