docs/admin/authorization: discourage the use rbac-super-user flag

Even though this flag works in 1.5, its use should be discouraged.
It will be removed in 1.6.
This commit is contained in:
Eric Chiang
2017-02-02 13:46:28 -08:00
committed by Andrew Chen
parent e3368b9733
commit 592d61c55c
+9 -9
View File
@@ -221,20 +221,20 @@ 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 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. 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 When bootstrapping, superuser credentials should include the `system:masters`
around these limitations. For the alpha release of RBAC, an API Server flag was group, for example by creating a client cert with `/O=system:masters`. This
added to allow one user to step around all RBAC authorization and privilege gives those credentials full access to the API and allows an admin to then set
escalation checks. NOTE: _This is subject to change with future releases._ up bindings for other users.
In Kubernetes versions 1.4 and 1.5, there was a similar flag that gave a user
full access:
``` ```
--authorization-rbac-super-user=admin --authorization-rbac-super-user=admin
``` ```
Once set the specified super user, in this case "admin", can be used to create __This flag will be removed in 1.6__. Admins should prefer the `system:masters`
the roles and role bindings to initialize the system. group when setting up clusters.
This flag is optional and once the initial bootstrapping is performed can be
unset.
### Roles, RolesBindings, ClusterRoles, and ClusterRoleBindings ### Roles, RolesBindings, ClusterRoles, and ClusterRoleBindings