What is Kubernetes RBAC: Roles, Permissions, and Policies Simplified

Role-based access control (RBAC) is a way to manage access to computer or network resources according to the roles of users in your organization. Kubernetes RBAC is crucial for maintaining a secure and intact cluster.

By using RBAC, organizations make sure that only authorized people can perform sensitive tasks, which lowers the chances of unintentional or harmful changes to the cluster’s state.

In this Guide, I’m discussing what RBAC Kubernetes is, how it works, the benefits, and a ClusterRole and RoleBinding Example. So Let’s Dive In!

What is Kubernetes RBAC?

Kubernetes role-based access control (RBAC) serves as a key security layer in Kubernetes. It manages access to the K8s API and its resources, enabling organizations to create user role names with defined permissions to determine who can view or interact with cluster resources.

This configuration also upholds the principle of least privilege (PoLP), ensuring users can only access the resources necessary for their specific role, thereby reducing the risk of breaches.

RBAC roles allow for detailed governance of Kubernetes resources, helping organizations meet regulatory requirements. This approach helps prevent unauthorized access and reduces risks by controlling access rights, which is a fundamental aspect of Kubernetes security best practices.

RBAC vs ABAC: What’s the difference?

Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) Overview

Role-Based Access Control (RBAC):

• RBAC is a system for groups of individuals who share common traits like departments, locations, job levels, and responsibilities.
• Permissions are assigned according to the role’s definition, which includes access rights, operations, and sessions.
• The National Institute of Standards and Technology identifies four types of RBAC: Flat, Hierarchical, Constrained, and Symmetrical.
• Level 1: The simplest RBAC form, based on roles for obtaining permissions.
• Level 2: Introduces role hierarchy and duty separation.
• Level 3: Incorporates duty separation and permission evaluations.
• Level 4: Expands on the Constrained RBAC model with added permission evaluations.

Attribute-Based Access Control (ABAC):

• Permissions are determined by user attributes, resource characteristics, or environmental factors.
• Administrators can assign permissions based on job title, tasks, seniority, file type, individual, or document sensitivity.
• ABAC provides detailed control, allowing for different permissions depending on location or day.
• Relationships are established through if/then conditions.

How RBAC in Kubernetes Works?

• The Kubernetes API server allows RBAC for both Users and Service Accounts.
• To set up RBAC, you need to enable the RBAC feature and create objects using resources from the Kubernetes RBAC authorization k8s.io v1 API.
• Roles: A set of permissions for specific actions on certain Kubernetes resource types.
• ClusterRoles: A non-namespaced option for resources at the cluster level.
• RoleBindings: Connections between Roles and Users or Service Accounts.
• ClusterRoleBinding: Similar to RoleBinding, but it targets ClusterRole resources instead of Roles.

The Importance of Kubernetes RBAC

• It stops unauthorized users from executing sensitive tasks that might endanger the cluster’s security.
• RBAC Kubernetes offers a system for controlling user permissions in a Kubernetes cluster.
• Access control rules can be created by setting default roles with specific permissions and linking these roles to users or service accounts.
• Kubernetes RBAC upholds the principle of least privilege, ensuring that users, services, applications, and connected devices have only the necessary permissions to carry out their functions.
• It boosts operational efficiency by automating access control based on established roles.
• It enables detailed and specific access control policies, allowing administrators to handle complex permission structures across various teams and applications.
• It enhances security by limiting access to cluster resources and minimizing the attack surface.
• It offers scalability and flexibility to manage access as the number of users, applications, and resources grows.
• It promotes the separation of duties within teams, restricting access to only the resources needed for particular roles.
• It aids in audits and compliance by carefully managing access and simplifying the auditing process through monitoring and recording access.

Roles vs ClusterRoles

Role binding allows users to have permissions in a specific namespace, whereas ClusterRoleBinding provides access across the entire cluster. It can refer to any Role within the same namespace or a ClusterRole, linking it to all namespaces in the cluster.

Unlike Roles, which are confined to a particular namespace, ClusterRoles enable cluster administrators to provide permissions throughout the whole cluster. ClusterRoles are utilized to allocate permissions that apply across the cluster, like permissions for actions that cover several namespaces or for resources that aren’t tied to a specific namespace (for instance, nodes).

Example Roles

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Example ClusterRoles

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

RoleBindings vs ClusterRoleBindings

Creating Roles and RoleBindings with YAML

Example: Create a namespace-scoped Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Example: RoleBinding for a ServiceAccount

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
- kind: ServiceAccount
  name: my-service-account
  namespace: dev
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Users vs Service Accounts

Before setting up RBAC Kubernetes, it’s crucial to grasp the Kubernetes user model. There are two ways to create ‘users’ based on the required access:

Users

In Kubernetes, a User signifies a person who logs into the cluster via an external service. You can utilize private keys (the standard method), a collection of usernames and passwords, or an OAuth service like Google Accounts. Kubernetes do not oversee users; there is no API object for them, so you cannot create them using Kubectl. Changes must be made at the external service provider.

Service Accounts

Service Accounts are token values that allow access to namespaces within your cluster. They are intended for applications and system components. Unlike Users, Service Accounts are supported by Kubernetes objects and can be managed through the API.

For simplicity, we will create a Service Account to represent our user in the upcoming tutorial. However, keep in mind that you should adhere to the steps in the Kubernetes documentation to connect your existing identity provider if you plan to add multiple human users to your cluster.

Setting up basic Kubernetes RBAC

First, let’s explore how to establish Kubernetes RBAC controls in your Kubernetes cluster:

Enhance Your CyerPanel Experience Today!

Discover a world of enhanced features and show your support for our ongoing development with CyberPanel add-ons. Elevate your experience today!

Learn More

1. Enable RBAC on your Kubernetes cluster

Make sure your Kubernetes API server starts with the –authorization-mode flag, which includes role-based access control.

In Kubernetes, the –authorization-mode flag sets the authorization methods that the API server will utilize. By adding Kubernetes RBAC to this flag, you allow it to manage authorization decisions within your cluster.

2. Define Roles and ClusterRoles

Assign Roles within a namespace to provide individual users or pods access to the necessary resources:

kind: Role<br>apiVersion: rbac.authorization.k8s.io/v1<br>metadata:<br>namespace: default<br>name: pod-reader<br>rules:apiGroups: [""]<br>resources: ["pods"]<br>verbs: ["get", "watch", "list"]

However, refrain from using asterisks in verbs or resource names unless absolutely required—they can inadvertently grant excessive access.

ClusterRoles provide permissions across the entire cluster. Use these for resources that need to be available throughout the cluster or for namespaces themselves:

kind: ClusterRole<br>apiVersion: rbac.authorization.k8s.io/v1<br>metadata:<br>name: node-reader<br>rules:
apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "watch", "list"]

3. Create RoleBindings and ClusterRoleBindings

RoleBindings assign specific permissions from a Role to a user or group of users.

Here’s an example that illustrates binding the pod-reader role to a user named Carl in the default namespace:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: default
subjects:
- kind: ServiceAccount
name: ci-bot
namespace: default
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io

ClusterRoleBindings extend the defined permissions in a ClusterRole across the whole cluster.

Below is an example that demonstrates binding the node-reader ClusterRole to all users in the group system:masters:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-nodes
subjects:
- kind: Group
  name: system:masters
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

Common Mistakes and How to Avoid Them

• When a role is suitable, create cluster roles
• Using wildcards (*) too much in verbs and resources
• Not creating a RoleBinding (a role without a subject is ineffective!)
• Across teams, excessive use of admin-level roles

Conclusion: Simplifying Security with RBAC Done Right

Kubernetes RBAC is your first line of defense but when implemented right, it empowers your teams without compromising your cluster. Use this guide to master the examples of Clustrerroles and Roles, audit regularly, and build roles with intention. If you follow these, your Kubernetes environment will be very safe, predictable, and easier to manage.

FAQ’s

1: What is the distinction between Role and ClusterRole? Roles are limited to a namespace, while ClusterRoles are applicable across the entire cluster or multiple namespaces.

2: Is it possible to assign a Role to several users? Yes, this can be done through RoleBindings that include multiple subjects.

3: Is RBAC turned on by default in Kubernetes? Yes, it is enabled by default for most managed Kubernetes services such as GKE, EKS, and AKS.

4: How can I check who accessed what? You can use audit logs and services like AWS CloudTrail (for EKS) or GCP Audit Logs (for GKE).

5: Can RBAC work with service meshes? Yes, tools like Istio can integrate with Kubernetes RBAC to provide detailed control.