Merge pull request #13750 from jimmycuadra/docs-accessing-the-api

Clarify authentication methods for k8s components
This commit is contained in:
Alex Mohr 2015-09-17 10:26:58 -07:00
commit 959c1a14cf

View File

@ -81,7 +81,8 @@ There are three differently configured serving ports because there are a
variety of uses cases:
1. Clients outside of a Kubernetes cluster, such as human running `kubectl`
on desktop machine. Currently, accesses the Localhost Port via a proxy (nginx)
running on the `kubernetes-master` machine. Proxy uses bearer token authentication.
running on the `kubernetes-master` machine. The proxy can use cert-based authentication
or token-based authentication.
2. Processes running in Containers on Kubernetes that need to read from
the apiserver. Currently, these can use a [service account](../user-guide/service-accounts.md).
3. Scheduler and Controller-manager processes, which need to do read-write
@ -92,18 +93,14 @@ variety of uses cases:
on different machines than the apiserver. Kubelet uses the Secure Port
to get their pods, to find the services that a pod can see, and to
write events. Credentials are distributed to kubelets at cluster
setup time. Kubelets use cert-based auth, while kube-proxy uses token-based auth.
setup time. Kubelet and kube-proxy can use cert-based authentication or token-based
authentication.
## Expected changes
- Policy will limit the actions kubelets can do via the authed port.
- Scheduler and Controller-manager will use the Secure Port too. They
will then be able to run on different machines than the apiserver.
- Clients, like kubectl, will all support token-based auth, and the
Localhost will no longer be needed, and will not be the default.
However, the localhost port may continue to be an option for
installations that want to do their own auth proxy.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/admin/accessing-the-api.md?pixel)]()