Recommended way to access r/w apiserver from container?

[justinsb]

I'd like to check that this is the recommended way to access the (read/write) apiserver from a container:

I think I am supposed to create a secret volume, using the kubecfg.crt / kubecfg.key / ca.crt that are saved locally for use with kubectl. I attach the secret volume to the pod. And then I access the API using the endpoint exposed through the environment variables, with my HTTP connection configured with the secrets from the volume mount.

Is that correct? (Is there a trick I'm missing?)

[erictune]

The basic workflow with creating a secret is right. However, you are at the cutting edge, so you are going to hit some bumps.

If you want to auth with the client cert, then you need to explicitly enable client-cert-based auth.
That is in plugin/pkg/auth/authenticator/request/x509.

If you want to auth using a token, then you need to teach the apiserver about that token. I'm working on that in #5470. You can copy that pattern if you know ahead of time the username you want this pod to run as, a cluster startup time (or are willing to modify the known_tokens.csv file and restart apiserver every time you want to add an account). More dynamic creation of accounts and tokens is definitely in the cards but not ready yet.

[erictune]

@liggitt @deads2k what flags does one need to enable to turn on union authenticator with x509 and token?

[erictune]

@justinsb I know I haven't actually explained how to turn on client cert authentication. That's because I don't know. I asked some people who might.

[liggitt]

@erictune client cert auth wasn't actually wired in all the way from command-line flags for the kubernetes apiserver. Opened #6190 as a first stab at it. The main point of contention would probably be how a client cert is mapped to a user name... the first pass just takes the common name of the client cert subject.

[erictune]

#6190 is merged.

@justinsb The thing you said in you said in your original post should now work. Interested to hear feedback on if it works and any friction.

[elibixby]

+1 also trying to implement this.

[elibixby]

@cjcullen advice for implementing this in GKE?

[cjcullen]

Justin's approach should also work with GKE once we support 0.15.0 (enables cert auth), but only on the :6443 endpoint. Eric's approach should also work, stuffing the token into a secret volume, but again, only on :6443 for now. Lastly, you could put the cluster's username/password into a secret, and craft a basic-auth request to hit the :443 R/W endpoint.

We definitely need a better story for this, but using a secret volume is one step better than using env vars or hardcoding credentials.