updated access to cluster/api w/o proxy post kube v1.3.2

docs/user-guide/accessing-the-cluster.md

@@ -69,7 +69,7 @@ $ curl http://localhost:8080/api/
 }
 ```
 
-#### Without kubectl proxy
+#### Without kubectl proxy (before v1.3.x)
 
 It is also possible to avoid using kubectl proxy by passing an authentication token
 directly to the apiserver, like this:
@@ -85,7 +85,29 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
 }
 ```
 
-The above example uses the `--insecure` flag.  This leaves it subject to MITM
+#### Without kubectl proxy (post v1.3.x)
+
+In recent versions of Kubernetes, `kubectl config view` no longer displays the token. Use `kubectl describe secret...` to get the token for the default service account, like this:
+
+``` shell
+$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
+$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d '\t')
+$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
+{
+  "kind": "APIVersions",
+  "versions": [
+    "v1"
+  ],
+  "serverAddressByClientCIDRs": [
+    {
+      "clientCIDR": "0.0.0.0/0",
+      "serverAddress": "10.0.1.149:443"
+    }
+  ]
+}
+```
+
+The above examples use the `--insecure` flag.  This leaves it subject to MITM
 attacks.  When kubectl accesses the cluster it uses a stored root certificate
 and client certificates to access the server.  (These are installed in the
 `~/.kube` directory).  Since cluster certificates are typically self-signed, it