Kubernetes RBAC escalation rule

If you are exploring the kubernetes RBAC then you must have to read this.

Let’s take an example: If user-1 can only access namespace-1 of kubernetes cluster with below permission.

- apiGroups: ["", "apps", "extensions"]
  resources: ["pods","deployments","statefulsets", "limitranges",         "secrets", "services", "configmaps","serviceaccounts", "pods/portforward"]
  verbs: ["*"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles", "rolebindings"]
  verbs: ["*"]

So, can user-1 create a role with the below permission?

- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

If you say “no” then you are wrong!!

Here the RBAC escalation rule came. In short, if you are granting “*” verbs on RBAC role/rolebinding objects then it will allow creating any role or rolebinding with any permissions.

Some of the important point you need to know:

1. You can only create/update a role if at least one of the following things is true:

• You already have all the permissions contained in the role, at the same scope as the object being modified (cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role).
• You are granted explicit permission to perform the escalate verb on the roles or clusterroles resource in the rbac.authorization.k8s.io API group.

2. You can only create/update a role binding if you already have all the permissions contained in the referenced role (at the same scope as the role binding) or if you have been authorized to perform the bind verb on the referenced role.

Reference:

• https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping
• https://jeremievallee.com/2018/05/28/kubernetes-rbac-namespace-user.html