RBAC

Tenant authorization is an important concept for Kubernetes Multi-Tenant security, especially in cases where tenants have direct access to the the Kubernetes API (e.g. Namespace As A Service).

Whilst clusters can have multiple authorization mechanisms in place, RBAC is a constant in almost every cluster.

There are some places where the architecture of RBAC makes this complex and allows for possible tenant privilege escalation

Privilege Escalation

There are quite a lot of rights that can be provided to individual users or groups that allow for esclation of privileges. Without additional controls letting a tenant create a pod on a shared node can lead to trivial privilege escalation as one example. The project maintains a list of known privilege esclations, but it’s worth noting that this only focuses on the core of Kubernetes and doesn’t account for any external software installed in the cluster.

Are namespaces namespaced?

One place where this problem is shown quite clearly is the namespace object itself. In a cluster where teants are granted edit or admin rights to their namespace and objects in it (quite a common configuration) they have the rights to edit their own namespace object.

At one level this sounds quite obvious, a namespace admin can administer their own namespace, but it opens up some interesting risks due to the way Kubernetes clsuters implement some security controls, via namespace labels. A good example of this is Pod Security Admission which restricts the rights that can be given to workloads in a given namespace. It does this via a label applied to the namespace to be restricted, so if a user has namespace edit rights, they can just change the label and escalate their privileges!