Benchmark to prevent privilege escalation

[Mac Chaffee]

There's a multi-tenancy benchmark that says users should have permission to create their own roles/rolebindings. And kubernetes has mechanisms for preventing a user from escalating their own privileges: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping

But it can be easy to get wrong. For example, if you grant all verbs like the following:

- apiGroups: ['rbac.authorization.k8s.io']
  resources: ['*']
  verbs: ['*']

That implicitly grants the "escalate" verb, which completely nullifies many other benchmarks like LimitRange/ResourceQuotas.

Since there's no complete list of verbs (even kubectl api-resources doesn't list the escalate verb), this may be a common mistake:

$ kubectl api-resources --api-group=rbac.authorization.k8s.io -o wide
NAME                  SHORTNAMES   APIVERSION                     NAMESPACED   KIND                 VERBS
clusterrolebindings                rbac.authorization.k8s.io/v1   false        ClusterRoleBinding   [create delete deletecollection get list patch update watch]
clusterroles                       rbac.authorization.k8s.io/v1   false        ClusterRole          [create delete deletecollection get list patch update watch]
rolebindings                       rbac.authorization.k8s.io/v1   true         RoleBinding          [create delete deletecollection get list patch update watch]
roles                              rbac.authorization.k8s.io/v1   true         Role                 [create delete deletecollection get list patch update watch]

Think it may be worthwhile to have a benchmark that ensures users don't have the that escalate verb.

Proposal

A simple kubectl auth can-i escalate role (or the client-go equivalent) should do the trick. A more complex check could involve attempting to escalate privs (bind to the cluster-admin clusterrole, or add the permission to delete LimitRanges to a role).

[Mac Chaffee]

Resolved by #1519