Merge pull request kubernetes#3048 from kubernetes/release-1.6

Merge Release 1.6 into Master, publishing documentation for 1.6 release

Author: devin-donnelly

_data/guides.yml

@@ -24,6 +24,7 @@ toc:
   - docs/user-guide/rolling-updates.md
   - docs/user-guide/update-demo/index.md
   - docs/user-guide/configmap/index.md
+  - docs/user-guide/projected-volume/index.md
   - docs/user-guide/horizontal-pod-autoscaling/walkthrough.md
   - docs/user-guide/config-best-practices.md
   - docs/user-guide/working-with-resources.md
@@ -107,6 +108,7 @@ toc:
       - docs/getting-started-guides/rackspace.md
       - docs/getting-started-guides/kops.md
       - docs/getting-started-guides/kargo.md
+      - docs/getting-started-guides/running-cloud-controller.md
     - title: On-Premise VMs
       section:
       - docs/getting-started-guides/coreos/index.md
@@ -167,6 +169,7 @@ toc:
   - docs/admin/upgrade-1-6.md
   - docs/admin/kubeadm.md
   - docs/admin/addons.md
+  - docs/admin/node-allocatable.md
   - docs/admin/audit.md
   - docs/admin/ha-master-gce.md
   - docs/admin/namespaces/index.md
@@ -180,6 +183,7 @@ toc:
   - docs/admin/sysctls.md
   - docs/admin/cluster-components.md
   - docs/admin/etcd.md
+  - docs/admin/etcd_upgrade.md
   - docs/admin/multi-cluster.md
   - title: Changing Cluster Size
     path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ#how-do-i-change-the-size-of-my-cluster/

_data/overrides.yml

@@ -1,17 +1,10 @@
 overrides:
-- path: docs/api-reference
-- path: docs/user-guide/kubectl
 - path: docs/admin/federation-apiserver.md
 - path: docs/admin/federation-controller-manager.md
 - path: docs/admin/kube-apiserver.md
 - path: docs/admin/kube-controller-manager.md
 - path: docs/admin/kube-proxy.md
 - path: docs/admin/kube-scheduler.md
 - path: docs/admin/kubelet.md
-- changedpath: docs/api-reference/extensions/v1beta1/definitions.html _includes/v1.5/extensions-v1beta1-definitions.html
-- changedpath: docs/api-reference/extensions/v1beta1/operations.html _includes/v1.5/extensions-v1beta1-operations.html
-- changedpath: docs/api-reference/v1/definitions.html _includes/v1.5/v1-definitions.html
-- changedpath: docs/api-reference/v1/operations.html _includes/v1.5/v1-operations.html
 - copypath: k8s/federation/docs/api-reference/ docs/federation/
 - copypath: k8s/cluster/saltbase/salt/fluentd-gcp/fluentd-gcp.yaml docs/getting-started-guides/fluentd-gcp.yaml
-

_data/reference.yml

@@ -3,18 +3,24 @@ abstract: "Design docs, concept definitions, and references for APIs and CLIs."
 toc:
 - docs/reference.md
 
-- title: "Kubernetes Resource Types (New Docs Style)"
+- title: "Kubernetes Resource Types"
   section:
+  - title: Version 1.6
+    path: /docs/resources-reference/v1.6/
   - title: Version 1.5
     path: /docs/resources-reference/v1.5/
 
-- title: "Kubernetes API (New Docs Style)"
+- title: "Kubernetes API"
   section:
+  - title: Version 1.6
+    path: /docs/api-reference/v1.6/
   - title: Version 1.5
     path: /docs/api-reference/v1.5/
 
-- title: "Kubectl Commands (New Docs Style)"
+- title: "Kubectl Commands"
   section:
+  - title: Version 1.6
+    path: /docs/user-guide/kubectl/v1.6/
   - title: Version 1.5
     path: /docs/user-guide/kubectl/v1.5/
 
@@ -25,7 +31,11 @@ toc:
     section:
     - docs/admin/accessing-the-api.md
     - docs/admin/authentication.md
-    - docs/admin/authorization.md
+    - docs/admin/bootstrap-tokens.md
+    - title: Authorization Plugins
+      section:
+      - docs/admin/authorization/index.md
+      - docs/admin/authorization/rbac.md
     - docs/admin/admission-controllers.md
     - docs/admin/service-accounts-admin.md
   - docs/api-reference/v1/operations.html
@@ -174,6 +184,7 @@ toc:
   - docs/user-guide/petset.md
   - docs/user-guide/pods/index.md
   - docs/user-guide/pod-security-policy/index.md
+  - docs/user-guide/pod-preset/index.md
   - docs/user-guide/replicasets.md
   - docs/user-guide/replication-controller/index.md
   - docs/admin/resourcequota/index.md

_data/tasks.yml

@@ -57,6 +57,10 @@ toc:
   section:
   - docs/tasks/access-kubernetes-api/http-proxy-access-api.md
 
+- title: Using TLS
+  section:
+  - docs/tasks/tls/managing-tls-in-a-cluster.md
+
 - title: Administering a Cluster
   section:
   - docs/tasks/administer-cluster/overview.md
@@ -65,6 +69,7 @@ toc:
   - docs/tasks/administer-cluster/safely-drain-node.md
   - docs/tasks/administer-cluster/change-pv-reclaim-policy.md
   - docs/tasks/administer-cluster/limit-storage-consumption.md
+  - docs/tasks/administer-cluster/change-default-storage-class.md
   - docs/tasks/administer-cluster/share-configuration.md
 
 - title: Administering Federation
@@ -85,3 +90,7 @@ toc:
   - docs/tasks/manage-stateful-set/deleting-a-statefulset.md
   - docs/tasks/manage-stateful-set/debugging-a-statefulset.md
   - docs/tasks/manage-stateful-set/delete-pods.md
+
+- title: Managing Cluster Daemons
+  section:
+  - docs/tasks/manage-daemon/update-daemon-set.md

docs/admin/accessing-the-api.md

@@ -3,13 +3,9 @@ assignees:
 - bgrant0607
 - erictune
 - lavalamp
-title: Overview
+title: Controlling Accessing to the Kubernetes API
 ---
 
-This document describes how access to the Kubernetes API is controlled.
-
-## Overview
-
 Users [access the API](/docs/user-guide/accessing-the-cluster) using `kubectl`,
 client libraries, or by making REST requests.  Both human users and
 [Kubernetes service accounts](/docs/user-guide/service-accounts/) can be
@@ -42,7 +38,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.
@@ -75,7 +71,7 @@ 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).
 
@@ -142,7 +138,7 @@ By default the Kubernetes API server serves HTTP on 2 ports:
 
   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.

docs/admin/authentication.md

@@ -107,6 +107,41 @@ header as shown below.
 Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
 ```
 
+### Bootstrap Tokens
+
+This feature is currently in **alpha**.
+
+To allow for streamlined bootstrapping for new clusters, Kubernetes includes a
+dynamically-managed Bearer token type called a *Bootstrap Token*. These tokens
+are stored as Secrets in the `kube-system` namespace, where they can be
+dynamically managed and created. Controller Manager contains a TokenCleaner
+controller that deletes bootstrap tokens as they expire.
+
+The tokens are of the form `[a-z0-9]{6}.[a-z0-9]{16}`.  The first component is a
+Token ID and the second component is the Token Secret.  You specify the token
+in an HTTP header as follows:
+
+```http
+Authorization: Bearer 781292.db7bc3a58fc5f07e
+```
+
+You must enable the Bootstrap Token Authenticator with the
+`--experimental-bootstrap-token-auth` flag on the API Server.  You must enable
+the TokenCleaner controller via the `--controllers` flag on the Controller
+Manager.  This is done with something like `--controllers=*,tokencleaner`.
+`kubeadm` will do this for you if you are using it to bootstrapping a cluster.
+
+The authenticator authenticates as `system:bootstrap:<Token ID>`.  It is
+included in the `system:bootstrappers` group.  The naming and groups are
+intentionally limited to discourage users from using these tokens past
+bootstrapping.  The user names and group can be used (and are used by `kubeadm`)
+to craft the appropriate authorization policies to support bootstrapping a
+cluster.
+
+Please see [Bootstrap Tokens](/docs/admin/bootstrap-tokens/) for in depth
+documentation on the Bootstrap Token authenticator and controllers along with
+how to manage these tokens with `kubeadm`.
+
 ### Static Password File
 
 Basic authentication is enabled by passing the `--basic-auth-file=SOMEFILE`
@@ -115,9 +150,10 @@ and the password cannot be changed without restarting API server. Note that basi
 authentication is currently supported for convenience while we finish making the
 more secure modes described above easier to use.
 
-The basic auth file is a csv file with a minimum of 3 columns: password,
-user name, user id, followed by optional group names. Note, if you have more than
-one group the column must be double quoted e.g.
+The basic auth file is a csv file with a minimum of 3 columns: password, user name, user id.
+In Kubernetes version 1.6 and later, you can specify an optional fourth column containing
+comma-separated group names. If you have more than one group, you must enclose the fourth
+column value in double quotes ("). See the following example:
 
 ```conf
 password,user,uid,"group1,group2,group3"
@@ -145,7 +181,7 @@ talk to the API server. Accounts may be explicitly associated with pods using th
 NOTE: `serviceAccountName` is usually omitted because this is done automatically.
 
 ```
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
@@ -459,11 +495,45 @@ HTTP status codes can be used to supply additional error context.
 
 The API server can be configured to identify users from request header values, such as `X-Remote-User`.
 It is designed for use in combination with an authenticating proxy, which sets the request header value.
+
+* `--requestheader-username-headers` Required, case-insensitive. Header names to check, in order, for the user identity. The first header containing a value is used as the username.
+* `--requestheader-group-headers` 1.6+. Optional, case-insensitive. "X-Remote-Group" is suggested. Header names to check, in order, for the user's groups. All values in all specified headers are used as group names.
+* `--requestheader-extra-headers-prefix` 1.6+. Optional, case-insensitive. "X-Remote-Extra-" is suggested. Header prefixes to look for to determine extra information about the user (typically used by the configured authorization plugin). Any headers beginning with any of the specified prefixes have the prefix removed, the remainder of the header name becomes the extra key, and the header value is the extra value.
+
+For example, with this configuration:
+```
+--requestheader-username-headers=X-Remote-User
+--requestheader-group-headers=X-Remote-Group
+--requestheader-extra-headers-prefix=X-Remote-Extra-
+```
+
+this request:
+```
+GET / HTTP/1.1
+X-Remote-User: fido
+X-Remote-Group: dogs
+X-Remote-Group: dachshunds
+X-Remote-Extra-Scopes: openid
+X-Remote-Extra-Scopes: profile
+```
+
+would result in this user info:
+```yaml
+name: fido
+groups:
+- dogs
+- dachshunds
+extra:
+  scopes:
+  - openid
+  - profile
+```
+
+
 In order to prevent header spoofing, the authenticating proxy is required to present a valid client
 certificate to the API server for validation against the specified CA before the request headers are
 checked.
 
-* `--requestheader-username-headers` Required, case-insensitive. Header names to check, in order, for the user identity. The first header containing a value is used as the identity.
 * `--requestheader-client-ca-file` Required. PEM-encoded certificate bundle. A valid client certificate must be presented and validated against the certificate authorities in the specified file before the request headers are checked for user names.
 * `--requestheader-allowed-names` Optional.  List of common names (cn). If set, a valid client certificate with a Common Name (cn) in the specified list must be presented before the request headers are checked for user names. If empty, any Common Name is allowed.
 
@@ -493,9 +563,6 @@ changes](https://github.com/kubernetes/kubernetes/pull/25536) for more details.
 
 ## Anonymous requests
 
-Anonymous access is enabled by default, and can be disabled by passing `--anonymous-auth=false`
-option to the API server during startup.
-
 When enabled, requests that are not rejected by other configured authentication methods are
 treated as anonymous requests, and given a username of `system:anonymous` and a group of
 `system:unauthenticated`.
@@ -504,8 +571,14 @@ For example, on a server with token authentication configured, and anonymous acc
 a request providing an invalid bearer token would receive a `401 Unauthorized` error.
 A request providing no bearer token would be treated as an anonymous request.
 
-If you rely on authentication alone to authorize access, either change to use an
-authorization mode other than `AlwaysAllow`, or set `--anonymous-auth=false`.
+In 1.5.1-1.5.x, anonymous access is disabled by default, and can be enabled by
+passing the `--anonymous-auth=false` option to the API server.
+
+In 1.6+, anonymous access is enabled by default if an authorization mode other than `AlwaysAllow`
+is used, and can be disabled by passing the `--anonymous-auth=false` option to the API server.
+Starting in 1.6, the ABAC and RBAC authorizers require explicit authorization of the
+`system:anonymous` user or the `system:unauthenticated` group, so legacy policy rules
+that grant access to the `*` user or `*` group do not include anonymous users.
 
 ## Plugin Development
 
@@ -525,7 +598,7 @@ using an existing deployment script or manually through `easyrsa` or `openssl.`
 #### Using an Existing Deployment Script
 
 **Using an existing deployment script** is implemented at
-`cluster/saltbase/salt/generate-cert/make-ca-cert.sh`.  
+`cluster/saltbase/salt/generate-cert/make-ca-cert.sh`.
 
 Execute this script with two parameters. The first is the IP address
 of API server. The second is a list of subject alternate names in the form `IP:<ip-address> or DNS:<dns-name>`.
@@ -586,3 +659,9 @@ Finally, add the following parameters into API server start parameters:
           openssl x509  -noout -text -in ./server.crt
 
 Finally, do not forget to fill out and add the same parameters into the API server start parameters.
+
+#### Certificates API
+
+You can use the `certificates.k8s.io` API to provision
+x509 certificates to use for authentication as documented
+[here](/docs/tasks/tls/managing-tls-in-a-cluster).