whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

move "Privilege Escalation Prevention and Bootstrapping closer

Browse Source 
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.

🐑
This commit is contained in:
Matthew Fisher
2016-11-17 13:05:45 -08:00
parent 7b2589f4f9
commit fdf250f86e
1 changed files with 23 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/admin/authorization.md
+23 -23
View File
@@ -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