From fdf250f86eb4e1a5b1a54da6cc9ddb6f320c1f21 Mon Sep 17 00:00:00 2001 From: Matthew Fisher Date: Thu, 17 Nov 2016 13:05:45 -0800 Subject: [PATCH] move "Privilege Escalation Prevention and Bootstrapping closer This way users don't have to read to the bottom to realize they need to add --authorization-rbac-super-user=admin to their cluster when bootstrapping for the first time. :sheep: --- docs/admin/authorization.md | 46 ++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/docs/admin/authorization.md b/docs/admin/authorization.md index a72a855cb2..1a86359a92 100644 --- a/docs/admin/authorization.md +++ b/docs/admin/authorization.md @@ -207,6 +207,29 @@ and [enable the API version]( /docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster), with a `--runtime-config=` that includes `rbac.authorization.k8s.io/v1alpha1`. +### Privilege Escalation Prevention and Bootstrapping + +The `rbac.authorization.k8s.io` API group inherently attempts to prevent users +from escalating privileges. Simply put, __a user can't grant permissions they +don't already have even when the RBAC authorizer it disabled__. If "user-1" +does not have the ability to read secrets in "namespace-a", they cannot create +a binding that would grant that permission to themselves or any other user. + +For bootstrapping the first roles, it becomes necessary for someone to get +around these limitations. For the alpha release of RBAC, an API Server flag was +added to allow one user to step around all RBAC authorization and privilege +escalation checks. NOTE: _This is subject to change with future releases._ + +``` +--authorization-rbac-super-user=admin +``` + +Once set the specified super user, in this case "admin", can be used to create +the roles and role bindings to initialize the system. + +This flag is optional and once the initial bootstrapping is performed can be +unset. + ### Roles, RolesBindings, ClusterRoles, and ClusterRoleBindings The RBAC API Group declares four top level types which will be covered in this @@ -417,29 +440,6 @@ subjects: name: system:serviceaccounts ``` -### Privilege Escalation Prevention and Bootstrapping - -The `rbac.authorization.k8s.io` API group inherently attempts to prevent users -from escalating privileges. Simply put, __a user can't grant permissions they -don't already have even when the RBAC authorizer it disabled__. If "user-1" -does not have the ability to read secrets in "namespace-a", they cannot create -a binding that would grant that permission to themselves or any other user. - -For bootstrapping the first roles, it becomes necessary for someone to get -around these limitations. For the alpha release of RBAC, an API Server flag was -added to allow one user to step around all RBAC authorization and privilege -escalation checks. NOTE: _This is subject to change with future releases._ - -``` ---authorization-rbac-super-user=admin -``` - -Once set the specified super user, in this case "admin", can be used to create -the roles and role bindings to initialize the system. - -This flag is optional and once the initial bootstrapping is performed can be -unset. - ## Webhook Mode When specified, mode `Webhook` causes Kubernetes to query an outside REST