Hacking around with kubernetes Authentication.

I've recently been experimenting with an option to auto-create NodePorts on APIServer startup.

To do this, I hacked around with some options on the kube hack/local-up-cluster.sh script in kube, but this is really a bad idea for any "real world" scenario.

However, it does give insight into how service endpoints authenticate requests, and how kubelets communicate securely  with the kubernetes api server.

So, I'm pasting a snippet of my doc updates (which won't get merged in with this patch for issue #13152) below.  

Please don't try to use any of the below options unless you've thoroughly followed issue #13152 and the associated Pull Request thoroughly, as it could change at any moment.

And at the time of this writing, the actual api-server-node-port option is changing to kubernetes-master-node-port (or something like that). 

Authentication via Kubeconfig files

You can test that kubeconfig files and certificates are working properly using local-up-cluster.

An example kubeconfig file can be found at Kubeconfig file, consult the docs for other details on authentication/authorization.

The key thing to remember is that the apiserver launches with certain credentials that kubelets or other users will need to provide when connecting, unless you use the insecure endpoint.

NodePorts or ClusterIPs as service endpoint for kubelets to access load balanced API Servers

First, you MUST launch BOTH the apiserver and kubelet with corresponding authentication credentials (the simplest way is to use a token file with a kubeconfig file passed to the kubelet).

Then, you can use ClusterIP or NodePort to provide a loadbalanced endpoint for the API servers to your kubelet, like so:

• ClusterIP: Launch kubelets with the --api-servers="https://10.0.0.1:443" option.
• NodePort: Modify the apiserver launch to include a NodePort range i.e. --service-node-port-range="30000-40000" with --apiserver-node-port="30279", and launch the kubelets with an --api-servers="https://127.0.0.1:30279" option.

Note the significance of https above: In both cases, it is needed because a TLS handshake will take place when connecting over a service endpoint, and in both examples above, we are having kubelets connect through a service (rather than directly) to apiservers.