Update RBAC docs for v1 (#5445)

docs/admin/authentication.md

@@ -638,7 +638,7 @@ authorization plugin, the following ClusterRole encompasses the rules needed to
 set user and group impersonation headers:
 
 ```yaml
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   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:
 
 ```yaml
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   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.
 
 ```yaml
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   name: limited-impersonator

docs/admin/authorization/index.md

@@ -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/).
  * **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.
- ..* As of 1.6 RBAC mode is in beta.
  ..* 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/).
 

docs/admin/authorization/rbac.md

@@ -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
 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`.
 
@@ -37,7 +37,7 @@ Here's an example `Role` in the "default" namespace that can be used to grant re
 
 ```yaml
 kind: Role
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   namespace: default
   name: pod-reader
@@ -59,7 +59,7 @@ or across all namespaces (depending on how it is [bound](#rolebinding-and-cluste
 
 ```yaml
 kind: ClusterRole
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   # "namespace" omitted since ClusterRoles are not namespaced
   name: secret-reader
@@ -82,7 +82,7 @@ This allows "jane" to read pods in the "default" namespace.
 ```yaml
 # This role binding allows "jane" to read pods in the "default" namespace.
 kind: RoleBinding
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: read-pods
   namespace: default
@@ -108,7 +108,7 @@ namespace (the namespace of the `RoleBinding`).
 ```yaml
 # This role binding allows "dave" to read secrets in the "development" namespace.
 kind: RoleBinding
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: read-secrets
   namespace: development # This only grants permissions within the "development" namespace.
@@ -129,7 +129,7 @@ secrets in any namespace.
 ```yaml
 # This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
 kind: ClusterRoleBinding
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: read-secrets-global
 subjects:
@@ -158,7 +158,7 @@ to read both pods and pod logs, you would write:
 
 ```yaml
 kind: Role
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   namespace: default
   name: pod-and-pod-logs-reader
@@ -175,7 +175,7 @@ configmap, you would write:
 
 ```yaml
 kind: Role
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   namespace: default
   name: configmap-updater
@@ -461,13 +461,14 @@ The permissions required by individual control loops are contained in the <a hre
 </tr>
 <tr>
 <td><b>system:node</b></td>
-<td><b>system:nodes</b> group (deprecated in 1.7, removed 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>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, when the `Node` authorization mode is enabled, the automatic binding to the `system:nodes` group is not created.
-As of 1.8, 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.
+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>
 </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:
 
 ```yaml
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   name: role-grantor
@@ -595,7 +596,7 @@ rules:
   verbs: ["bind"]
   resourceNames: ["admin","edit","view"]
 ---
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: RoleBinding
 metadata:
   name: role-grantor-binding

docs/admin/kubelet-tls-bootstrapping.md

@@ -99,7 +99,7 @@ may be automatically created in future releases.
 # A ClusterRole which instructs the CSR approver to approve a user requesting
 # node client credentials.
 kind: ClusterRole
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: approve-node-client-csr
 rules:
@@ -110,7 +110,7 @@ rules:
 # A ClusterRole which instructs the CSR approver to approve a node renewing its
 # own client credentials.
 kind: ClusterRole
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: approve-node-client-renewal-csr
 rules:
@@ -121,7 +121,7 @@ rules:
 # A ClusterRole which instructs the CSR approver to approve a node requesting a
 # serving cert matching its client cert.
 kind: ClusterRole
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: approve-node-server-renewal-csr
 rules:
@@ -143,7 +143,7 @@ An admin would create a `ClusterRoleBinding` targeting that group.
 ```yml
 # Approve all CSRs for the group "system:bootstrappers"
 kind: ClusterRoleBinding
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: auto-approve-csrs-for-group
 subjects:
@@ -161,7 +161,7 @@ that node's credentials:
 
 ```yml
 kind: ClusterRoleBinding
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: node1-client-cert-renewal
 subjects:

docs/tasks/administer-cluster/configure-multiple-schedulers.md

@@ -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:
 ```
 $ kubectl edit clusterrole system:kube-scheduler
-- apiVersion: rbac.authorization.k8s.io/v1beta1
+- apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     annotations:

docs/tasks/debug-application-cluster/event-exporter-deploy.yaml

@@ -6,7 +6,7 @@ metadata:
   labels:
     app: event-exporter
 ---
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: event-exporter-rb