Kubernetes RBAC: Best Practices & Examples

RBAC (Role-Based Access Control) is a key feature of Kubernetes that allows administrators to control access to cluster resources by defining Roles and assigning permissions to different users, groups, and service accounts. As the number of users and workloads in a Kubernetes cluster grows, managing access control becomes increasingly complex. Using RBAC, you can manage access control at a higher level using configuration management tools. You can define access control policies as code and version them with the rest of the infrastructure. Following Kubernetes RBAC best practices gives many security advantages, such as fine-grained access control and the ability to define Roles with minimal permissions.

This article covers the fundamental concepts of Kubernetes RBAC along with some practical use cases.

Here are some best practices for using Kubernetes RBAC.

By following these best practices, you can ensure that your Kubernetes cluster is secure and that users only have access to the resources they need to do their jobs. Before implementing RBAC, you must understand its core components and possible actions.

RBAC consists of four key components: Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings.

Roles

A Role is a set of rules defining permissions for accessing Kubernetes resources within a specific namespace. You can use a Role to grant a number of read or write actions to a specific set of resources, such as pods or services, within a namespace.

RoleBindings

A RoleBinding attaches a Role to a user, group, or service account. It grants the permissions defined in a Role to the specified user, group, or service account within the specified namespace.

ClusterRoles

ClusterRoles are similar to Roles but affect the entire Kubernetes cluster instead of a specific namespace. You can use a ClusterRole to grant a number of read or write actions to a set of resources outside a specific namespace, such as nodes or namespaces.

ClusterRoleBindings

ClusterRoleBindings are similar to RoleBindings, but you use them to attach a ClusterRole to a user, group, or service account. A ClusterRoleBinding grants permissions defined in a ClusterRole to the specified user, group, or service account across the Kubernetes cluster.

Verbs define the actions you can perform on Kubernetes resources.
Kubernetes administrators use verbs in conjunction with Roles and RoleBindings (or ClusterRoles and ClusterRoleBindings) to grant or restrict access to specific actions on Kubernetes resources. The following are the possible verbs that you can use in RBAC. You can also use wildcards.

Now that you understand the basics of RBAC, let's explore some key Kubernetes RBAC best practices!

The most important of all Kubernetes RBAC best practices involves granting users or service accounts only the permissions they need to perform their tasks. For example, let's say you have a service account used by a specific pod in your Kubernetes cluster to access a database. In this case, you might create a custom Role that grants the service account read and write access to the specific database but no access to other resources in the cluster.

Default RBAC Roles

Cluster-admin and system:masters are built-in Kubernetes RBAC Roles that grant users or service accounts powerful permissions across the entire cluster. Both Roles are included in Kubernetes by default, but you should only use them when absolutely necessary.

Cluster-admin

The cluster-admin Role grants full control over all resources in the cluster, including the ability to create, modify, and delete resources in any namespace. This Role is for cluster administrators who need full control over the cluster and should be used cautiously as it grants unrestricted access.

System:masters

The system:masters Role grants read and write access to most resources in the cluster but does not grant full control over the cluster. Users or service accounts with this Role can create, modify, and delete resources in most namespaces. Still, they cannot perform certain privileged operations, such as modifying the cluster's control plane components. This Role suits users or service accounts needing elevated permissions to perform specific administrative tasks.

More granular Roles

In general, it is preferable to create fine-grained Roles and permissions for users or service accounts that need to access specific resources or perform specific actions. Granting them the cluster-admin or system:masters Roles can increase security risks. Fine-grained access control reduces the risk of accidental modifications to critical resources in the cluster.

Namespaces are the Kubernetes way to section off resources in a multi-tenant environment. Each namespace will have its own set of resources and policies.

Using namespaces with RBAC, you can create more fine-grained access controls that apply only to specific resources within a particular namespace.

For example, multiple development teams use a Kubernetes cluster, each working on their own microservices. You could use namespaces to partition the cluster’s resources for each team and use RBAC to grant each one only the permissions needed to access their resources.

Namespaces manifest example

Here's an example manifest for creating a custom RBAC Role that grants a user or service account access to resources in a specific namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: mynamespace
  name: myRole
rules:
- apiGroups: [""]
  resources: ["pods", "services", "deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

This manifest creates a custom Role called myRole in the namespace mynamespace. The Role grants the get, list, and watch verbs for the pods, services, and deployments resources, as well as the create, update, patch, and delete verbs for these resources. This allows the associated user or service account to view, create, modify, and delete resources in the specific namespace.

You use a service account in Kubernetes to authenticate and authorize communication between different parts of the system, such as pods or controllers. When you create a pod in Kubernetes, it is automatically assigned a default service account, which you use to access the Kubernetes API and other resources.

How to create a service account

To define an RBAC service account in Kubernetes, you can create a ServiceAccount resource, like this:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myserviceaccount
  namespace: mynamespace

This manifest creates a new service account called myserviceaccount in the namespace mynamespace. Pods or controllers can use the service account to authenticate and authorize communication with other system parts.

Granting permissions to the service account

Once you create the service account, you can create RBAC policies that grant specific permissions to the service account. This is done using the Role and RoleBinding resources, which define the specific actions and resources the service account can access. For example, attach a Role to the service account using a RoleBinding:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myserviceaccount
  namespace: mynamespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: myRoleBinding
  namespace: mynamespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: myRole
subjects:
- kind: ServiceAccount
  name: myserviceaccount
  namespace: mynamespace

The Rolebinding above requires a separate Role resource to be defined as follows:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: myRole
  namespace: mynamespace
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

This manifest creates a Role called myRole in the namespace mynamespace. The Role grants the following permissions:

• Read access to all secrets in the namespace (get, list, and watch verbs).
• Read access to all pods and logs in the namespace (get and list verbs).

Using a ClusterRole with a ServiceAccount

Following on from the previous example, what if we needed Cluster-wide permissions for our service account? After creating the ServiceAccount we can attach a ClusterRole using a ClusterRoleBinding:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myserviceaccount
  namespace: mynamespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: myClusterRoleBinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: myserviceaccount
  namespace: mynamespace

This manifest creates a ServiceAccount called “myserviceaccount” and assigns the default ClusterRole “cluster-admin” to the ServiceAccount.

It's important to note that granting the "cluster-admin" ClusterRole to a ServiceAccount should be done with caution, as it provides full access to all resources in the cluster. It's generally best to use more specific Roles and RoleBindings whenever possible to limit access to only the resources and actions that are necessary.

RBAC policies should be defined and managed as code in Kubernetes using YAML manifests, whether in versioned helm charts or source control. With that in mind, one of the most important Kubernetes RBAC best practices is regularly reviewing your RBAC policies and ensuring they meet your organization's security requirements. You could also consider using a third-party policy enforcement agent like OPA Gatekeeper.

OPA Gatekeeper

Open Policy Agent (OPA) is an open-source, general-purpose policy engine. OPA Gatekeeper is a Kubernetes-based validating admission webhook that enforces OPA policies on interactions with Kubernetes resources. You can use it to ensure all applications deployed to your target Kubernetes cluster have defined custom service accounts.

To recap, using the principle of Least Privilege is vitally important as it reduces the blast radius in the event of unauthorized access, a data breach, and other security incidents. Likewise, using namespaces helps create fine-grained controls that limits vulnerability. The third principle follows from the least privilege, using service accounts where possible and keeping user permissions to an absolute minimum. Finally, all RBAC policies should be updated continually as your organization's needs and security requirements change.

RBAC (Role-Based Access Control) is a powerful mechanism for controlling access to resources in a cluster. Following Kubernetes RBAC best practices, you ensure your Kubernetes cluster is secure and well-managed. At the same time, It is important to remember that RBAC policies are only one part of a comprehensive security strategy and should be used in conjunction with other security mechanisms such as network policies, encryption, and authentication.