kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #40527 from Zhuzhenghao/rbac 

Cleanup page rbac
pull/40526/head
Kubernetes Prow Robot 2023-04-05 18:35:49 -07:00 committed by GitHub
parent e24f5267a8 3a3ae711d5
commit 263bf7f59b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 150 additions and 141 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
content/en/docs/reference/access-authn-authz/rbac.md
View File

@ -261,7 +261,6 @@ When specified, requests can be restricted to individual instances of a resource
Here is an example that restricts its subject to only `get` or `update` a
{{< glossary_tooltip term_id="ConfigMap" >}} named `my-configmap`:
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
@ -306,12 +305,15 @@ rules:
```
{{< caution >}}
Using wildcards in resource and verb entries could result in overly permissive access being granted to sensitive resources.
For instance, if a new resource type is added, or a new subresource is added, or a new custom verb is checked, the wildcard entry automatically grants access, which may be undesirable.
The [principle of least privilege](/docs/concepts/security/rbac-good-practices/#least-privilege) should be employed, using specific resources and verbs to ensure only the permissions required for the workload to function correctly are applied.
Using wildcards in resource and verb entries could result in overly permissive access being granted
to sensitive resources.
For instance, if a new resource type is added, or a new subresource is added,
or a new custom verb is checked, the wildcard entry automatically grants access, which may be undesirable.
The [principle of least privilege](/docs/concepts/security/rbac-good-practices/#least-privilege)
should be employed, using specific resources and verbs to ensure only the permissions required for the
workload to function correctly are applied.
{{< /caution >}}
### Aggregated ClusterRoles
You can _aggregate_ several ClusterRoles into one combined ClusterRole.
@ -625,7 +627,10 @@ Auto-reconciliation is enabled by default if the RBAC authorizer is active.
### API discovery roles {#discovery-roles}
Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible (including CustomResourceDefinitions). To disable anonymous unauthenticated access, add `--anonymous-auth=false` to the API server configuration.
Default role bindings authorize unauthenticated and authenticated users to read API information
that is deemed safe to be publicly accessible (including CustomResourceDefinitions).
To disable anonymous unauthenticated access, add `--anonymous-auth=false` to
the API server configuration.
To view the configuration of these roles via `kubectl` run:
@ -901,15 +906,19 @@ You can only create/update a role if at least one of the following things is tru
1. You already have all the permissions contained in the role, at the same scope as the object being modified
(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role).
2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group.
2. You are granted explicit permission to perform the `escalate` verb on the `roles` or
`clusterroles` resource in the `rbac.authorization.k8s.io` API group.
For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole
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 permission to include specific permissions in the roles they create/update:
* implicitly, by giving them those permissions (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)
* or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group
* implicitly, by giving them those permissions (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)
* or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them
permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the
`rbac.authorization.k8s.io` API group
### Restrictions on role binding creation or update