Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document cross-authorizer permissions for creating RBAC roles #10015

Merged
merged 2 commits into from
Sep 20, 2018
Merged

Document cross-authorizer permissions for creating RBAC roles #10015

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8df6f11
Document cross-authorizer permissions for creating RBAC roles
liggitt Aug 14, 2018
0d4aec2
Update rbac.md
zparnold Sep 20, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions content/en/docs/reference/access-authn-authz/rbac.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -662,13 +662,19 @@ 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