Kubernetes RBAC Security Pitfalls

My previous blogpost covered the basics of the Kubernetes Role-Based Access control (RBAC) module. Here, I want to provide some common mistakes and vulnerabilities that you probably want to know about when designing, configuring or auditing Kubernetes authorization. This post is not a complete guide to Kubernetes or RBAC security and only covers a few specific aspects.

Generally, the same principles as with any access control system apply. If you do not have a clear access-control configuration strategy and do not keep your RBAC rules and configurations clean, you will make mistakes. I will not repeat these basics here, but let’s rather investigate some Kubernetes RBAC peculiarities here.

Horizontal privilege escalation via cluster nodes (multi-tenancy)

It is important to understand that the RBAC module only covers Kubernetes API access. Access to Kubernetes (API) resources, such as pod-, secret- or service definitions can be controlled. However, what cannot be controlled with authorization modules is what’s happening directly on or via cluster nodes.

Let’s say we have a cluster with multiple nodes and namespaces. Users of one namespace should not be able to access other namespaces’ resources. People might make the mistake to assume that this separation between namespaces can be enforced with RBAC alone. They might configure a role allowed to create and access pods in its own namespace only. However, since this role can create arbitrary pods, the users bound to that role can easily access other namespaces by creating a privileged pod and accessing the host through that pod. Once on the host, other namespaces’ pods can be accessed and compromised. The user can probably even get access to the other namespaces’ API resources (e.g. by reading out service account tokens from victim pods).

So, assuming RBAC provides a strong isolation mechanism by itself is dangerous. This attack scenario could be prevented with stringent pod security policies not allowing privileged pods or any host access. Although conceptually secure if configured correctly, it is not very robust, since it relies on the security of the container, which, for most container runtimes, is the implementation of cgroups and namespaces by the kernel. It could be hardened further with alternative container runtimes providing stronger security properties, but if this can fulfill the security requirements of your applications and data needs to be considered on a case-by-case basis.

Vertical privilege escalation via create pod privilege

Be aware that users with the permission to create pods can escalate their privileges easily. This is because any service account can be provided in the pod specification. The token secret of the selected service account will be mapped into the container and it can be used for API access. So, the create pod privilege implicitly allows to impersonate any service account within the same namespace.

Privilege escalation via impersonate permissions

As the name suggests, the impersonate verb on user/group/serviceaccount resources lets a subject impersonate someone else. With kubectl, impersonation can be done with the “–as” and “–as-groups” arguments, such as:

kubectl –as=system:admin get secrets

Be careful if you want to provide this privilege, since this might mean you give over full control over your cluster.

Privilege escalation via bind or escalate permissions

As explained in my previous blogpost, the RBAC module prevents users from escalating their privileges by adding or modifying roles or rolebindings. However, the bind verb on (cluster)rolebindings or the escalate verb on (cluster)roles bypass these restrictions. So, e.g. having modify and escalate permission on role resources allows users to add arbitrary permissions to their roles. So, users with these privileges can create new roles or rolebindings exceeding their own privileges.

General recommendations

• If you need multi-tenancy or want to isolate security and failure domains, use separate clusters with separate nodes. If you don’ want to do that, design your Kubernetes security architecture carefully and be aware of residual risks.
• Use different service accounts for different types of workloads and apply the principle of least privilege.
• Be aware of the implications with the create pod privilege.
• Check for potentially dangerous privileges (e.g. impersonate, bind, escalate).
• The granularity RBAC offers increases overall complexity. Keep your RBAC clean and easy to understand. Strictly apply naming conventions.
• Be careful with duplicated role grants. When revoking privileges, mistakes might happen.
• Avoid bindings to missing roles. When adding a role with the same name, users or serviceaccounts might suddenly get privileges not intended to provide to them.
• Avoid unused roles to decrease complexity.
• Regularly audit your clusters’ RBAC configurations.