Add details on Bootstrap Tokens

docs/admin/accessing-the-api.md

@@ -42,7 +42,7 @@ The input to the authentication step is the entire HTTP request, however, it typ
 just examines the headers and/or client certificate.
 
 Authentication modules include Client Certificates, Password, and Plain Tokens,
-and JWT Tokens (used for service accounts).
+Bootstrap Tokens, and JWT Tokens (used for service accounts).
 
 Multiple authentication modules can be specified, in which case each one is tried in sequence,
 until one of them succeeds.
@@ -63,7 +63,7 @@ users in its object store.
 
 Once the request is authenticated as coming from a specific user,
 it moves to a generic authorization step.  This is shown as step **2** in the
-diagram. 
+diagram.
 
 The input to the Authorization step are attributes of the REST request, including:
   - the username determined by the Authentication step.
@@ -75,12 +75,12 @@ The input to the Authorization step are attributes of the REST request, includin
 
 There are multiple supported Authorization Modules.  The cluster creator configures the API
 server with which Authorization Modules should be used.  When multiple Authorization Modules
-are configured, each is checked in sequence, and if any Module authorizes the request, 
+are configured, each is checked in sequence, and if any Module authorizes the request,
 then the request can proceed.  If all deny the request, then the request is denied (HTTP status
 code 403).
 
 The [Authorization Modules](/docs/admin/authorization) page describes what authorization modules
-are available and how to configure them.    
+are available and how to configure them.
 
 For version 1.2, clusters created by `kube-up.sh` are configured so that no authorization is
 required for any request.
@@ -108,7 +108,7 @@ They act on objects being created, deleted, updated or connected (proxy), but no
 
 Multiple admission controllers can be configured.  Each is called in order.
 
-This is shown as step **3** in the diagram. 
+This is shown as step **3** in the diagram.
 
 Unlike Authentication and Authorization Modules, if any admission controller module
 rejects, then the request is immediately rejected.
@@ -122,7 +122,7 @@ Once a request passes all admission controllers, it is validated using the valid
 for the corresponding API object, and then written to the object store (shown as step **4**).
 
 
-## API Server Ports and IPs 
+## API Server Ports and IPs
 
 The previous discussion applies to requests sent to the secure port of the API server
 (the typical case).  The API server can actually serve on 2 ports:
@@ -141,8 +141,8 @@ By default the Kubernetes API server serves HTTP on 2 ports:
           - protected by need to have host access
 
   2. `Secure Port`:
- 
-          - use whenever possible 
+
+          - use whenever possible
           - uses TLS.  Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag.
           - default is port 6443, change with `--secure-port` flag.
           - default IP is first non-localhost network interface, change with `--bind-address` flag.