Clarify authentication methods for k8s components.

docs/admin/accessing-the-api.md

@@ -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)]()