Skip to content

Commit

Permalink
Document cross-authorizer permissions for creating RBAC roles
Browse files Browse the repository at this point in the history
  • Loading branch information
liggitt committed Aug 21, 2018
1 parent f8e4d35 commit 8df6f11
Showing 1 changed file with 8 additions and 3 deletions.
11 changes: 8 additions & 3 deletions content/en/docs/reference/access-authn-authz/rbac.md
Original file line number Diff line number Diff line change
Expand Up @@ -662,13 +662,18 @@ These roles include:
The RBAC API prevents users from escalating privileges by editing roles or role bindings.
Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use.

A user can only create/update a role if they already have all the permissions contained in the role,
at the same scope as the role (cluster-wide for a `ClusterRole`, within the same namespace or cluster-wide for a `Role`).
A user can only create/update a role if at least one of the following things is true:
1. they 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. they are given explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group (Kubernetes 1.12 and newer)

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 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.
2. Grant them permission to include specific permissions in the roles the 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 (Kubernetes 1.12 and newer)

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.
Expand Down

0 comments on commit 8df6f11

Please sign in to comment.