Introduction
In this guide, we provide Kubernetes RBAC best practices, with the top 2 tips for avoiding excessive permissions in Kubernetes RBAC. Kubernetes is a powerful platform that allows users to manage and deploy containerized applications with ease. However, creating excessive RBAC permissions is all too easy and can result in security vulnerabilities that can be exploited by attackers. For an expanded list with the top 5 tips from the OWASP Top 10 for Kubernetes, Kubernetes.io and other industry experts, download the guide below.
1. Watch Out for Defaults
Defaults are probably the singular most common way to accidentally get yourself into trouble with over-permissions in Kubernetes RBAC because there are so many unintuitive default settings that you would not predict. For example, if you don’t remove bindings from the system:unauthenticated group, any of those bindings can allow anonymous users to contact the API server via the network. It's important to review and modify the default settings to ensure that you're not granting more permissions than necessary.
2. Look for the big ones
We need to go no further than the OWASP top 10 for Kubernetes to understand the biggest over permissions gotchas with RBAC.
Cluster-admin
The Kubernetes super user is a cluster-admin, which gives anybody the capability to do - well, anything - in a cluster. The example used in the OWASP guidance details a third-party Kubernetes observability tool that was given cluster-admin access. Unfortunately, this tool's UI was accidentally exposed via a Load Balancer with a public IP address. This means that an attacker could gain access to the Kubernetes API and receive permission to do anything that would help it escalate its privileges throughout the cluster. Generally, a role or cluster role should be created instead of using cluster-admin, and generally, service accounts don't need this kind of access.
System:masters
Anybody who is a member of the system:masters group is automatically granted cluster-admin access. This is true even if you delete all the roles in the cluster, with no RBAC policies, anybody who is a member of this group gets full access.
3. Avoid this Kubernetes verbs list
Escalate, Bind, and Impersonate
The escalate verb allows - surprisingly - you to escalate your privileges. Another way of gaining rights to something not already permitted is using the verb bind, which will effectively grant access to the rights of other roles. Another way to accomplish a similar increase in permissions is to use the impersonate verb.
How KSOC can help
KSOC can help you gain an aggregate view of the permissions subjects have today. We start with a simple question, "What can any subject do in my cluster?" The screenshot below shows aggregated permissions for get, list and watch, as mentioned above.
Conclusion
Avoiding excessive permissions in Kubernetes RBAC requires more than understanding the biggest gotchas or understanding potential pitfalls in the defaults. It involves careful planning, organization, and monitoring. Check out the full guide for the top 5 tips including verbs to watch out for, permission that beget permissions and how to get organized so you can avoid over-permissioning in Kubernetes RBAC. For more information about KSOC can help, sign up for a demo.
