github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #42088 from ericchiang/psp-example-fix 

Automatic merge from submit-queue

PodSecurityPolicy example: fix explanation

cc @kubernetes/sig-auth-pr-reviews

```release-note
NONE
```
pull/6/head
Kubernetes Submit Queue 2017-03-30 15:24:53 -07:00 committed by GitHub
parent 30e010da3b 8cb6eb0b21
commit eaa386167a
1 changed files with 11 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
examples/podsecuritypolicy/rbac/README.md
View File

@ -82,21 +82,25 @@ podsecuritypolicy "restricted" created
### Roles and bindings
In order to a `PodSecurityPolicy` a user must have the ability to perform the `use` verb on the policy.
The `use` verb is a special verb that grants access to use the policy while
not allowing any other access. This verb is specific to `PodSecurityPolicy`.
To enable the `use` access we will create cluster roles. In this example we will provide the roles:
In order to create a pod, either the creating user or the service account
specified by the pod must be authorized to use a `PodSecurityPolicy` object
that allows the pod. That authorization is determined by the ability to perform
the `use` verb on a particular `podsecuritypolicies` resource. The `use` verb
is a special verb that grants access to use a policy while not permitting any
other access. For this example, we'll first create RBAC `ClusterRoles` that
enable access to `use` specific policies.
1. `restricted-psp-user`: this role allows the `use` verb on the `restricted` policy only
2. `privileged-psp-user`: this role allows the `use` verb on the `privileged` policy only
To associate roles with users we will use groups via a `RoleBinding`. This example uses
the following groups:
We can then create `ClusterRoleBindings` to grant groups of users the
"restricted" and/or "privileged" `ClusterRoles`. In this example, the bindings
grant the following roles to groups.
1. `privileged`: this group is bound to the `privilegedPSP` role and `restrictedPSP` role which gives users
in this group access to both policies.
1. `restricted`: this group is bound to the `restrictedPSP` role
1. `restricted`: this group is bound to the `restrictedPSP` role.
1. `system:authenticated`: this is a system group for any authenticated user. It is bound to the `edit`
role which is already provided by the cluster.