Minikube: Should set the RequestHeader Client CA options

[DirectXMan12]

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
FEATURE REQUEST

Minikube should generate and pass in a RequestHeader client CA (in addition to the normal client CA) so that the extension-apiserver-authentication ConfigMap is autopopulated with the requestheader client CA (see https://github.com/kubernetes/kubernetes/blob/master/pkg/master/client_ca_hook.go).

This is used by custom API servers to trust the authentication information passed to them by the API server aggregator proxy (a separate pod in 1.6, is/will be part of the master for 1.7). The generic API server code automatically tries to use the information in this map (when the requestheader client CA is not manually passed via a command line option), so having the value populated is useful even when the user is not running the proxy.

cc @pmorie @arschles kubernetes-incubator/service-catalog#737

[dlorenc]

Do you have any more docs available on how this CA cert should be created? Or any pointers to how the CA is managed in other distros would be helpful.

[DirectXMan12]

Documentation can be found in the Kubernetes authentication documentation here under the Authentication Proxy section.

It's a client CA certificate, just like the normal client CA, except that any client with a certificate signed by this CA is effectively allowed to masquerade as any identity (and thus needs to be its own CA, not an existing one).

[MHBauer]

Further docs in kubernetes-incubator/service-catalog#745

@DirectXMan12 is the aggregator pod something that should be added to the add-on manager like DNS?

@dlorenc is there a way to get a v1.7-dev image or otherwise generate one manually from the kubernetes code and then install it into minikube?

[DirectXMan12]

@DirectXMan12 is the aggregator pod something that should be added to the add-on manager like DNS?

You could do that. The version in 1.6 is a bit finicky to get set up, since it's a separate pod (it needs in-Kube DNS, so it generally needs to be running in a pod, but it has a bit of a bootstrap problem). Once you hit 1.7, there's nothing separate to set up, though.

[krancour]

Has anyone started work on this? I want to avoid overlapping efforts, but this is a feature that @arschles and I want pretty badly, so I'm about to start work on it.

[dlorenc]

I don't think anyone has started. A contribution would be very welcome!

[krancour]

Ok. Will get to work on this after the holiday weekend.

[munnerz]

I'm trying to set up e2e tests of a custom API server using minikube and am now running into this!

Happy to assist pushing this forward.

[krancour]

I have this _almost_ working.

[munnerz]

I've managed to get this working for now by adding the following arguments to the custom API server that I'm running:

          - --requestheader-client-ca-file=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
          - --requestheader-username-headers=X-Remote-User
          - --requestheader-group-headers=X-Remote-Group
          - --requestheader-extra-headers-prefix=X-Remote-Extra

This allows it to start up without relying on the 'main' API server to provide the requestheader CA file. It may not work in all environments (it definitely doesn't work on GKE), but it does work for me with minikube!

Tests now passing 💯 https://travis-ci.org/jetstack-experimental/navigator/jobs/272491496

[dlorenc]

@krancour Thanks! Feel free to send a WIP PR and we can take a look and try to help get it working.