From ba9f7f10e21f3c0b4c9394bbb90e2913dd0d4529 Mon Sep 17 00:00:00 2001 From: yanghaichao12 Date: Wed, 13 Mar 2019 03:20:40 +0800 Subject: [PATCH] Revise some places (#13012) * Revert "Fix a typos" This reverts commit 5dcca521c40f214b261ceac8db9bd027dc463fbc. * Revise some places temporary --- content/en/docs/reference/access-authn-authz/rbac.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index cccdcf255d..f2cb82bec9 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -695,9 +695,9 @@ Because this is enforced at the API level, it applies even when the RBAC authori 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 +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) +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: