Update RBAC docs for v1 (#5445)

This commit is contained in:
Jordan Liggitt
2017-09-13 16:22:55 -04:00
committed by Steve Perry
parent 178a2d0f26
commit 2a7a878d0e
7 changed files with 30 additions and 30 deletions
+5 -5
View File
@@ -99,7 +99,7 @@ may be automatically created in future releases.
# A ClusterRole which instructs the CSR approver to approve a user requesting # A ClusterRole which instructs the CSR approver to approve a user requesting
# node client credentials. # node client credentials.
kind: ClusterRole kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: approve-node-client-csr name: approve-node-client-csr
rules: rules:
@@ -110,7 +110,7 @@ rules:
# A ClusterRole which instructs the CSR approver to approve a node renewing its # A ClusterRole which instructs the CSR approver to approve a node renewing its
# own client credentials. # own client credentials.
kind: ClusterRole kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: approve-node-client-renewal-csr name: approve-node-client-renewal-csr
rules: rules:
@@ -121,7 +121,7 @@ rules:
# A ClusterRole which instructs the CSR approver to approve a node requesting a # A ClusterRole which instructs the CSR approver to approve a node requesting a
# serving cert matching its client cert. # serving cert matching its client cert.
kind: ClusterRole kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: approve-node-server-renewal-csr name: approve-node-server-renewal-csr
rules: rules:
@@ -143,7 +143,7 @@ An admin would create a `ClusterRoleBinding` targeting that group.
```yml ```yml
# Approve all CSRs for the group "system:bootstrappers" # Approve all CSRs for the group "system:bootstrappers"
kind: ClusterRoleBinding kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: auto-approve-csrs-for-group name: auto-approve-csrs-for-group
subjects: subjects:
@@ -161,7 +161,7 @@ that node's credentials:
```yml ```yml
kind: ClusterRoleBinding kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: node1-client-cert-renewal name: node1-client-cert-renewal
subjects: subjects:
+3 -3
View File
@@ -638,7 +638,7 @@ authorization plugin, the following ClusterRole encompasses the rules needed to
set user and group impersonation headers: set user and group impersonation headers:
```yaml ```yaml
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole kind: ClusterRole
metadata: metadata:
name: impersonator name: impersonator
@@ -653,7 +653,7 @@ allow a user to use impersonation headers for the extra field "scopes," a user
should be granted the following role: should be granted the following role:
```yaml ```yaml
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole kind: ClusterRole
metadata: metadata:
name: scopes-impersonator name: scopes-impersonator
@@ -667,7 +667,7 @@ The values of impersonation headers can also be restricted by limiting the set
of `resourceNames` a resource can take. of `resourceNames` a resource can take.
```yaml ```yaml
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole kind: ClusterRole
metadata: metadata:
name: limited-impersonator name: limited-impersonator
-1
View File
@@ -62,7 +62,6 @@ of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authoriz
* **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/). * **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/) * **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. ..* 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.
..* As of 1.6 RBAC mode is in beta.
..* To enable RBAC, start the apiserver with `--authorization-mode=RBAC`. ..* 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/). * **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/).
+15 -14
View File
@@ -13,7 +13,7 @@ Role-Based Access Control ("RBAC") uses the "rbac.authorization.k8s.io" API grou
to drive authorization decisions, allowing admins to dynamically configure policies to drive authorization decisions, allowing admins to dynamically configure policies
through the Kubernetes API. through the Kubernetes API.
As of 1.6 RBAC mode is in beta. As of 1.8, RBAC mode is stable and backed by the rbac.authorization.k8s.io/v1 API.
To enable RBAC, start the apiserver with `--authorization-mode=RBAC`. To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
@@ -37,7 +37,7 @@ Here's an example `Role` in the "default" namespace that can be used to grant re
```yaml ```yaml
kind: Role kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
namespace: default namespace: default
name: pod-reader name: pod-reader
@@ -59,7 +59,7 @@ or across all namespaces (depending on how it is [bound](#rolebinding-and-cluste
```yaml ```yaml
kind: ClusterRole kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
# "namespace" omitted since ClusterRoles are not namespaced # "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader name: secret-reader
@@ -82,7 +82,7 @@ This allows "jane" to read pods in the "default" namespace.
```yaml ```yaml
# This role binding allows "jane" to read pods in the "default" namespace. # This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: read-pods name: read-pods
namespace: default namespace: default
@@ -108,7 +108,7 @@ namespace (the namespace of the `RoleBinding`).
```yaml ```yaml
# This role binding allows "dave" to read secrets in the "development" namespace. # This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: read-secrets name: read-secrets
namespace: development # This only grants permissions within the "development" namespace. namespace: development # This only grants permissions within the "development" namespace.
@@ -129,7 +129,7 @@ secrets in any namespace.
```yaml ```yaml
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace. # This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: read-secrets-global name: read-secrets-global
subjects: subjects:
@@ -158,7 +158,7 @@ to read both pods and pod logs, you would write:
```yaml ```yaml
kind: Role kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
namespace: default namespace: default
name: pod-and-pod-logs-reader name: pod-and-pod-logs-reader
@@ -175,7 +175,7 @@ configmap, you would write:
```yaml ```yaml
kind: Role kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
namespace: default namespace: default
name: configmap-updater name: configmap-updater
@@ -461,13 +461,14 @@ The permissions required by individual control loops are contained in the <a hre
</tr> </tr>
<tr> <tr>
<td><b>system:node</b></td> <td><b>system:node</b></td>
<td><b>system:nodes</b> group (deprecated in 1.7, removed in 1.8)</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 pods</b>. <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/) As of 1.7, use of the [Node authorizer](/docs/admin/authorization/node/)
and [NodeRestriction admission plugin](/docs/admin/admission-controllers#NodeRestriction) 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. 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, when the `Node` authorization mode is enabled, the automatic binding to the `system:nodes` group is not created. Prior to 1.7, this role was automatically bound to the `system:nodes` group.
As of 1.8, the automatic binding to the `system:nodes` group is not created. 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.
</td> </td>
</tr> </tr>
<tr> <tr>
@@ -582,7 +583,7 @@ to a role that grants that permission. To allow a user to create/update role bin
For example, this cluster role and role binding would allow "user-1" to grant other users the `admin`, `edit`, and `view` roles in the "user-1-namespace" namespace: For example, this cluster role and role binding would allow "user-1" to grant other users the `admin`, `edit`, and `view` roles in the "user-1-namespace" namespace:
```yaml ```yaml
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole kind: ClusterRole
metadata: metadata:
name: role-grantor name: role-grantor
@@ -595,7 +596,7 @@ rules:
verbs: ["bind"] verbs: ["bind"]
resourceNames: ["admin","edit","view"] resourceNames: ["admin","edit","view"]
--- ---
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding kind: RoleBinding
metadata: metadata:
name: role-grantor-binding name: role-grantor-binding
+5 -5
View File
@@ -99,7 +99,7 @@ may be automatically created in future releases.
# A ClusterRole which instructs the CSR approver to approve a user requesting # A ClusterRole which instructs the CSR approver to approve a user requesting
# node client credentials. # node client credentials.
kind: ClusterRole kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: approve-node-client-csr name: approve-node-client-csr
rules: rules:
@@ -110,7 +110,7 @@ rules:
# A ClusterRole which instructs the CSR approver to approve a node renewing its # A ClusterRole which instructs the CSR approver to approve a node renewing its
# own client credentials. # own client credentials.
kind: ClusterRole kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: approve-node-client-renewal-csr name: approve-node-client-renewal-csr
rules: rules:
@@ -121,7 +121,7 @@ rules:
# A ClusterRole which instructs the CSR approver to approve a node requesting a # A ClusterRole which instructs the CSR approver to approve a node requesting a
# serving cert matching its client cert. # serving cert matching its client cert.
kind: ClusterRole kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: approve-node-server-renewal-csr name: approve-node-server-renewal-csr
rules: rules:
@@ -143,7 +143,7 @@ An admin would create a `ClusterRoleBinding` targeting that group.
```yml ```yml
# Approve all CSRs for the group "system:bootstrappers" # Approve all CSRs for the group "system:bootstrappers"
kind: ClusterRoleBinding kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: auto-approve-csrs-for-group name: auto-approve-csrs-for-group
subjects: subjects:
@@ -161,7 +161,7 @@ that node's credentials:
```yml ```yml
kind: ClusterRoleBinding kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
metadata: metadata:
name: node1-client-cert-renewal name: node1-client-cert-renewal
subjects: subjects:
@@ -100,7 +100,7 @@ First, update the following fields in your YAML file:
If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add you scheduler name to the resourceNames of the rule applied for endpoints resources, as in the following example: If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add you scheduler name to the resourceNames of the rule applied for endpoints resources, as in the following example:
``` ```
$ kubectl edit clusterrole system:kube-scheduler $ kubectl edit clusterrole system:kube-scheduler
- apiVersion: rbac.authorization.k8s.io/v1beta1 - apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole kind: ClusterRole
metadata: metadata:
annotations: annotations:
@@ -6,7 +6,7 @@ metadata:
labels: labels:
app: event-exporter app: event-exporter
--- ---
apiVersion: rbac.authorization.k8s.io/v1beta1 apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding kind: ClusterRoleBinding
metadata: metadata:
name: event-exporter-rb name: event-exporter-rb