Resolving merge conflicts with master

2017-11-30 18:53:33 -06:00
parent 53f460ad9e a49d85186a
commit 538dd33ff2
5068 changed files with 25074 additions and 855452 deletions
@@ -53,7 +53,7 @@ DELETE    | delete (for individual resources), deletecollection (for collections
 Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:

 * [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) checks for authorization of the `use` verb on `podsecuritypolicies` resources in the `extensions` API group.
-* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization 
+* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization
 of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
 * [Authentication](/docs/admin/authentication/) layer checks for authorization of the `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.

@@ -61,8 +61,8 @@ of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authoriz
 * **Node** - A special-purpose authorizer that grants permissions to kubelets based on the pods they are scheduled to run. To learn more about using the Node authorization mode, see [Node Authorization](/docs/admin/authorization/node/).
 * **ABAC** - Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes etc). To learn more about using the ABAC mode, see [ABAC Mode](/docs/admin/authorization/abac/).
 * **RBAC** - Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. To learn more about using the RBAC mode, see [RBAC Mode](/docs/admin/authorization/rbac/)
- ..* When specified "RBAC" (Role-Based Access Control) uses the "rbac.authorization.k8s.io" API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API.
- ..* To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
+   * When specified "RBAC" (Role-Based Access Control) uses the "rbac.authorization.k8s.io" API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API.
+   * To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
 * **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/admin/authorization/webhook/).

 #### Checking API Access
@@ -132,10 +132,11 @@ The following flags can be used:
  * `--authorization-mode=ABAC` Attribute-Based Access Control (ABAC) mode allows you to configure policies using local files.
  * `--authorization-mode=RBAC` Role-based access control (RBAC) mode allows you to create and store policies using the Kubernetes API.
  * `--authorization-mode=Webhook` WebHook is an HTTP callback mode that allows you to manage authorization using a remote REST.
+  * `--authorization-mode=Node` Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
  * `--authorization-mode=AlwaysDeny` This flag blocks all requests. Use this flag only for testing.
  * `--authorization-mode=AlwaysAllow` This flag allows all requests. Use this flag only if you do not require authorization for your API requests.

-You can choose more than one authorization module. If one of the modes is `AlwaysAllow`, then it overrides the other modes and all API requests are allowed. 
+You can choose more than one authorization module. If one of the modes is `AlwaysAllow`, then it overrides the other modes and all API requests are allowed.

 ## Versioning
 For version 1.2, clusters created by kube-up.sh are configured so that no authorization is required for any request.
@@ -9,7 +9,7 @@ title: Using RBAC Authorization
 * TOC
 {:toc}

-Role-Based Access Control ("RBAC") uses the "rbac.authorization.k8s.io" API group 
+Role-Based Access Control ("RBAC") uses the "rbac.authorization.k8s.io" API group
 to drive authorization decisions, allowing admins to dynamically configure policies
 through the Kubernetes API.

@@ -123,7 +123,7 @@ roleRef:
 ```

 Finally, a `ClusterRoleBinding` may be used to grant permission at the cluster level and in all
-namespaces. The following `ClusterRoleBinding` allows any user in the group "manager" to read 
+namespaces. The following `ClusterRoleBinding` allows any user in the group "manager" to read
 secrets in any namespace.

 ```yaml
@@ -267,7 +267,7 @@ reserved for Kubernetes system use, and so the admin should ensure
 usernames do not contain this prefix by accident.

 Group information in Kubernetes is currently provided by the Authenticator
-modules. Groups, like users, are represented as strings, and that string 
+modules. Groups, like users, are represented as strings, and that string
 has no format requirements, other than that the prefix `system:` is reserved.

 [Service Accounts](/docs/tasks/configure-pod-container/configure-service-account/) have usernames with the `system:serviceaccount:` prefix and belong
@@ -368,7 +368,7 @@ and updates default cluster role bindings with any missing subjects.
 This allows the cluster to repair accidental modifications,
 and to keep roles and rolebindings up-to-date as permissions and subjects change in new releases.

-To opt out of this reconciliation, set the `rbac.authorization.kubernetes.io/autoupdate` 
+To opt out of this reconciliation, set the `rbac.authorization.kubernetes.io/autoupdate`
 annotation on a default cluster role or rolebinding to `false`.
 Be aware that missing default permissions and subjects can result in non-functional clusters.

@@ -463,9 +463,7 @@ The permissions required by individual control loops are contained in the <a hre
 <td><b>system:node</b></td>
 <td>None in 1.8+</td>
 <td>Allows access to resources required by the kubelet component, <b>including read access to all secrets, and write access to all pod status objects</b>.
-As of 1.7, use of the [Node authorizer](/docs/admin/authorization/node/) 
-and [NodeRestriction admission plugin](/docs/admin/admission-controllers#NodeRestriction) 
-is recommended instead of this role, and allow granting API access to kubelets based on the pods scheduled to run on them.
+As of 1.7, use of the <a href="/docs/admin/authorization/node/">Node authorizer</a> and <a href="/docs/admin/admission-controllers/#noderestriction">NodeRestriction admission plugin</a> is recommended instead of this role, and allow granting API access to kubelets based on the pods scheduled to run on them.
 Prior to 1.7, this role was automatically bound to the `system:nodes` group.
 In 1.7, this role was automatically bound to the `system:nodes` group if the `Node` authorization mode is not enabled.
 In 1.8+, no binding is automatically created.
@@ -506,7 +504,7 @@ This is commonly used by add-on API servers for unified authentication and autho
 <tr>
 <td><b>system:kube-dns</b></td>
 <td><b>kube-dns</b> service account in the <b>kube-system</b> namespace</td>
-<td>Role for the <a href="/docs/admin/dns/">kube-dns</a> component.</td>
+<td>Role for the <a href="/docs/concepts/services-networking/dns-pod-service/">kube-dns</a> component.</td>
 </tr>
 <tr>
 <td><b>system:node-bootstrapper</b></td>
@@ -530,7 +528,7 @@ This is commonly used by add-on API servers for unified authentication and autho
 The [Kubernetes controller manager](/docs/admin/kube-controller-manager/) runs core control loops.
 When invoked with `--use-service-account-credentials`, each control loop is started using a separate service account.
 Corresponding roles exist for each control loop, prefixed with `system:controller:`.
-If the controller manager is not started with `--use-service-account-credentials`, 
+If the controller manager is not started with `--use-service-account-credentials`,
 it runs all control loops using its own credential, which must be granted all the relevant roles.
 These roles include:

@@ -570,7 +568,7 @@ containing that permission. To allow a user to create/update roles:
 1. Grant them a role that allows them to create/update `Role` or `ClusterRole` objects, as desired.
 2. Grant them roles containing the permissions you would want them to be able to set in a `Role` or `ClusterRole`. If they attempt to create or modify a `Role` or `ClusterRole` with permissions they themselves have not been granted, the API request will be forbidden.

-A user can only create/update a role binding if they already have all the permissions contained in the referenced role 
+A user can only create/update a role binding if they already have all the permissions contained in the referenced role
 (at the same scope as the role binding) *or* if they've been given explicit permission to perform the `bind` verb on the referenced role.
 For example, if "user-1" does not have the ability to list secrets cluster-wide, they cannot create a `ClusterRoleBinding`
 to a role that grants that permission. To allow a user to create/update role bindings:
@@ -669,7 +667,7 @@ In order from most secure to least secure, the approaches are:
   and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.).

   For example, grant read-only permission within "my-namespace" to the "my-sa" service account:
-   
+
   ```shell
   kubectl create rolebinding my-sa-view \
     --clusterrole=view \
@@ -684,7 +682,7 @@ In order from most secure to least secure, the approaches are:
   NOTE: Permissions given to the "default" service account are available to any pod in the namespace that does not specify a `serviceAccountName`.

   For example, grant read-only permission within "my-namespace" to the "default" service account:
-   
+
   ```shell
   kubectl create rolebinding default-view \
     --clusterrole=view \
@@ -694,9 +692,9 @@ In order from most secure to least secure, the approaches are:

   Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the "kube-system" namespace.
   To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the "kube-system" namespace.
-   
+
   NOTE: Enabling this means the "kube-system" namespace contains secrets that grant super-user access to the API.
-   
+
   ```shell
   kubectl create clusterrolebinding add-on-cluster-admin \
     --clusterrole=cluster-admin \
@@ -709,7 +707,7 @@ In order from most secure to least secure, the approaches are:
   you can grant a role to the service account group for that namespace.

   For example, grant read-only permission within "my-namespace" to to all service accounts in that namespace:
-   
+
   ```shell
   kubectl create rolebinding serviceaccounts-view \
     --clusterrole=view \
@@ -722,7 +720,7 @@ In order from most secure to least secure, the approaches are:
   If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts.

   For example, grant read-only permission across all namespaces to all service accounts in the cluster:
-   
+
   ```shell
   kubectl create clusterrolebinding serviceaccounts-view \
     --clusterrole=view \
@@ -20,7 +20,7 @@ service when determining user privileges.
 Mode `Webhook` requires a file for HTTP configuration, specify by the
 `--authorization-webhook-config-file=SOME_FILENAME` flag.

-The configuration file uses the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The configuration file uses the [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
 file format. Within the file "users" refers to the API Server webhook and
 "clusters" refers to the remote service.

@@ -31,8 +31,10 @@ A configuration example which uses HTTPS client auth:
 clusters:
  - name: name-of-remote-authz-service
    cluster:
-      certificate-authority: /path/to/ca.pem      # CA for verifying the remote service.
-      server: https://authz.example.com/authorize # URL of remote service to query. Must use 'https'.
+      # CA for verifying the remote service.
+      certificate-authority: /path/to/ca.pem
+      # URL of remote service to query. Must use 'https'. May not include parameters.
+      server: https://authz.example.com/authorize

 # users refers to the API Server's webhook configuration.
 users: