Secure access to minikube

[sebgoa]

We should have secure access to minikube.
Even with a self signed cert, it should be https and with token access.

[dlorenc]

+1. This is definitely a requirement, even for local clusters.

[dlorenc]

This will have a lot in common with #10 . We can re-use the certificate generation from this PR: redspread/localkube#50 and make sure to pass a secure bind address/PORT to the API server later in initialization.

Note that we'll need a way to transfer the certs back out of the VM with this approach, though. It looks like most of Docker machine does this the other way: certs are generated on the client and uploaded to the server.

[dlorenc]

Here's how most k8s distributions seem to generate the certs:
https://github.com/kubernetes/kubernetes/blob/master/cluster/saltbase/salt/generate-cert/make-ca-cert.sh

We could run this from the client, then use SSH to "cat" the files to retrieve the contents and place them in a local directory for kubectl to use.

[dlorenc]

cc @vishh @ethernetdan @Runseb
We need to figure out the user experience of minikube with certs. I have a prototype that prints out the commands a user should run:

Run these commands to use the cluster: 
kubectl config set-cluster minikube --server=https://192.168.99.100:443 --certificate-authority=$HOME/.minikube/ca.crt
kubectl config set-credentials minikube --client-certificate=$HOME/.minikube/kubecfg.crt --client-key=$HOME/.minikube/kubecfg.key
kubectl config use-context minikube

But that isn't terribly user friendly. What do you think about having minikube write it's own kubecfg file, and then provide a $(minikube init) function that exports the KUBECONFIG env variable to point kubectl at this file?

Experienced users can then run minikube init without the $() to see the parameters so they can use this cluster in their main kubecfg if they want to.

[vishh]

@dlorenc why not update the kube config directly from minikube? We can reserve a cluster name, minikube for example, and keep updating that cluster, whenever the certs and IP changes.

[dlorenc]

We could update that cluster as well. We'd then have to make sure to also set the context so a bare "kubectl get pods" or something works, without the user needing to specify the context.

Do you think changing the context automatically would be surprising to users that have multiple clusters?

[vishh]

Given that people who run minikube intend to use it right way, I feel the
default action of updating the context to point to the local cluster should
be OK. If it affects users, they can always switch the "current cluster" in
the context pretty easily. WDYT?

On Thu, Apr 28, 2016 at 1:49 PM, dlorenc notifications@github.com wrote:

We could update that cluster as well. We'd then have to make sure to also
set the context so a bare "kubectl get pods" or something works, without
the user needing to specify the context.

Do you think changing the context automatically would be surprising to
users that have multiple clusters?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#11 (comment)

[dlorenc]

Prototype here: https://github.com/dlorenc/minikube/tree/auth

Need to get localkube merged in here, and some changes made to localkube to support certs.

[dlorenc]

Closed with #48

[dlorenc]

We still have some follow on work to make the configuration easier, though. See #50