Guide to Kubernetes RBAC

In this article, you will learn what RBAC is, the key challenges and approaches to managing RBAC in Kubernetes, and how Cerbos can help you in your application security.

In Kubernetes, when a request comes to the API Server to create resources, it processes the request in different steps. It first checks from where a request is made and whether a user is valid or not. This process is called authentication. There are two categories of users: normal users and service accounts. Service accounts are managed internally by Kubernetes, and are used by applications that access the cluster, such as the Monitoring Application. Normal users are external entities that may include administrators, developers, and other humans.

After authentication, the next process is authorization for the requested action and permissions. While Kubernetes supports multiple authorization methods, the one we’ll concentrate on in this article is called RBAC.

What is RBAC?

RBAC stands for Role Based Access Control. It is a method through which we can control access to resources and actions based on the roles assigned to the users. In Kubernetes, RBAC is how the administrator can control and allow which actions the users can perform on which resources, respectively. RBAC is managed just like everything else in Kubernetes: as objects that can be described via YAML or kubectl. To enable RBAC, the --authorization-mode flag must be set to RBAC when starting the API server.

kube-apiserver --authorization-mode=RBAC

Core objects of Kubernetes RBAC

The RBAC API declares four core objects. These are:

1. Role: It is a way of defining what actions users can perform within a namespace. This defines which actions such as get, list, create, delete, etc., can be performed on specific resources like pods, services, and deployments.
2. Cluster Role: This is similar to the role, but it is used for cluster-wide permissions. It means it is not limited to a specific namespace and can be used in all namespaces of the cluster.
3. RoleBinding: RoleBinding binds the role with one or more users, groups, and service accounts in a particular namespace. In this way, whatever permissions we have defined in a role get allotted to the users, groups, or service accounts.
4. ClusterRoleBinding: ClusterRoleBinding binds the ClusterRole to one or more users, groups, and service accounts throughout the cluster. This allows the permissions defined in ClusterRole to be assigned to users in all namespaces of the cluster.

How RBAC is implemented in Kubernetes

It depends on your requirements and what you want to create for your resources, whether it be a Role or a ClusterRole.

Create a role and assign it with RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: default
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "list", "update", "delete", "create"]

We have permitted pods to get, list, update, delete, and create the resources.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devuser-developer-binding
subjects:
- kind: User
  name: dev-user # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

RoleBinding binds the developer Role to a user named dev-user in the default namespace.

Create a ClusterRole and assign it with ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-administrator
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["nodes"]
  verbs: ["get", "list", "delete", "create"]

We have permitted nodes to get, list, delete, and create the resources.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-role-binding
subjects:
- kind: User
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-administrator
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding binds the cluster-administrator ClusterRole to a user named cluster-admin in all namespaces.

Challenges in Kubernetes RBAC

1. Difficulty in management: It's difficult to manage RBAC in Kubernetes when you have so many roles and permissions. Each user and service requires particular permission, which can be time-consuming and complex. As the number of users, applications, and namespaces grows, it becomes difficult to handle the RBAC configuration. For example, if you have a team of developers in different namespaces, you must ensure that each developer can only access the resources that they need. Mistakenly, if any developer gets too many permissions, they can unintentionally modify other's resources.

2. Scalability issues: As the organization grows, so does the number of users and roles. This growth is asymmetrical, and the challenge of scaling RBAC manually can quickly become overwhelming. It becomes a huge task to manage and define permissions for each employee. A minor error can lead to a security breach or any operational issue.

3. Manual process: When you configure and define RBAC roles and permissions manually, it can be quite dangerous. Even a small mistake can lead to a security breach. For example, if an administrator has to permit the developer only to read but mistakenly gives permission to him to write as well, then the developer can modify data, which can lead to vulnerabilities.

4. Logs auditing and compliance: It is necessary to maintain accurate and detailed records for auditing and compliance. To follow standards such as GDPR and HIPAA, you have to maintain detailed logs that show which users performed what actions and when. Kubernetes provides limited tools for RBAC auditing, which makes compliance challenging.

Approaches to addressing Kubernetes RBAC challenges

1. Implementing principle of least privilege: Least Privilege means you have to give minimum permissions to the users they need to do their work. Too many permissions can result in security issues. You should follow the least privilege approach to enhance security.

2. Policy management tools: Managing too many policies can be difficult. You can use policy management tools to reduce the burden of managing policies. These tools can create, update, and manage policies for you and ensure RBAC policies are up-to-date and secure.

3. Namespaced roles: You should use namespace roles to limit the scope of your resources. With a namespaced role, you can ensure that a user or service only gets access to the resources in that namespace that are necessary for their function. This isolation helps us prevent accidental access.

4. Auditing RBAC regularly: You should audit your RBAC configuration regularly. With regular lookups on these configurations, you can timely identify issues and fix them.

It's clear that managing Kubernetes access and permissions is quite complex, but it provides a robust security feature at the infrastructure level, and is well worth considering for your future deployments.

Bring powerful RBAC to your applications

Finally, if you're looking to bring that same infrastructure-level power to the application layer, you should check out Cerbos. The Cerbos Policy Decision Point (PDP) is a scalable, open source authorization layer for implementing roles and permissions. It can be deployed easily as a sidecar alongside your Kubernetes-managed applications.