Update README directions for authenticating within a cluster

[jeremywadsack]

As mentioned in #213, the recommended way to connect within a cluster is a little different than what's documented in the README. This resolves that by updating the documented approach.

I removed the reference to kubernetes issue 7101 because kubernetes has moved beyond the work discussed there.

Most of this text is taken directly from the Kubernetes documentation, although I edited it a bit.

[cben]

Looks great!

cc @carbonin, you have experience with in-cluster kubeclient use, could you reveiw as well? I see in manageiq we do this slightly differently — env vars vs kubernetes.default DNS, /run vs /var/run.

• This PR looks consistent with official doc https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-api-from-a-pod.
• KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT weren't set in pod env kubernetes/kubernetes#40973 sounds like DNS is more reliable than env vars (asked over there to confirm)

[cben]

https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-api-from-a-pod documents kubernetes.default. I suspect kubernetes works too but only from pod running in default namespace?

BTW, consider linking to that doc.

[jeremywadsack]

Hmm... I found different instructions at https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod (linked in the PR). Adding a link in the docs here is a good idea, but we need to decide which one is the right one. :) Reading the two, I think your link is more accurate / more recent?

On a separate note, I see that the link you shared says "Official client libraries do this automatically." I would like a feature where kubeclient can automatically authenticate itself where possible (e.g. within a cluster). However, from the discussions we've had, it sounds like you're more inclined to have authentication be explicit.

[cben]

LOL. I'm hoping to get some answers on kubernetes/kubernetes#40973.

[liggitt]

opened kubernetes/website#8166 to fix the docs

[carbonin]

This looks about right to me.

We do exactly this in manageiq here but we use the environment variables.

I haven't seen issues where they are not set, but if the guidance is to use DNS we can change.

[cben]

I would like a feature where kubeclient can automatically authenticate itself where possible (e.g. within a cluster). However, from the discussions we've had, it sounds like you're more inclined to have authentication be explicit.

Connecting to kubernetes from within kubernetes is 100% in scope for kubeclient!
Note sure about 100% automagic but AFAICT official clients don't do that either — you're supposed to know you're in a cluster and call an InClusterConfig method, and we could do this too.

BTW, we've recently heard about https://github.com/kubernetes-client/ruby, a still-early official kubernetes ruby client. I intend to reach out to the authors and compare long-term plans; in particular I suspect config-related code and APIs could be shared...

[cben]

Tested in a pod (on openshift). Authenticated as system:serviceaccount:ruby:default (was in namespace called ruby).
Got User system:serviceaccount:ruby:default cannot list pods error but that's just the default permissions, worked after creating a role & binding (https://stackoverflow.com/a/47973891/239657).