Kubernetes RBAC Tutorial With Example

Introduction

Managing access to resources is critical in the vast Kubernetes ecosystem for maintaining a secure and well-organized cluster. In this Kubernetes RBAC tutorial, role-based access control (RBAC) emerges as a key player, providing a robust mechanism for defining and enforcing access policies. In this article, we will look at the fundamentals of RBAC in Kubernetes and walk through a practical example to show how it can be used. If you are a beginner and want to learn more about Kubernetes, you can read Main Components of Kubernetes Architecture.

How RBAC Works

When a user or service account tries to perform an action in the cluster, the Kubernetes API server checks the RBAC policies to see if the action is permitted. RBAC is intended to adhere to the principle of least privilege, ensuring that entities are only granted the permissions required for their specific tasks.

Know Everything About Kubernetes RBAC

Components of RBAC

1. Roles and ClusterRoles

Roles and ClusterRoles define sets of permissions for resources within a specific namespace and across the entire cluster, respectively. They serve as the foundation for defining which actions are permitted on which resources.

Roles:

Roles define a set of permissions within a specific namespace. They define which actions (verbs) can be performed on which resources (nouns) within that namespace. A role, for example, might enable a user to list and retrieve pods in a specific namespace.

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

ClusterRoles:

ClusterRoles extend the concept of roles to a cluster-wide scope. They define permissions that apply across all namespaces. ClusterRoles are appropriate for actions that have an impact on the entire cluster, such as node management or cluster-wide monitoring.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-manager
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "delete"]

2. RoleBindings and ClusterRoleBindings

RoleBindings and ClusterRoleBindings associate roles and cluster roles with subjects, such as users, groups, or service accounts. These bindings determine who has access to the defined permissions.

RoleBindings:

A RoleBinding associates a role with a user, group, or service account within a specific namespace. It establishes the link between subjects (entities) and roles, determining who has access to what resources.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: my-namespace
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBindings:

ClusterRoleBindings, like RoleBindings, associate cluster roles with subjects. However, they operate at a cluster-wide level, influencing access across all namespaces.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: node-manager-binding
subjects:
- kind: User
  name: bob
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-manager
  apiGroup: rbac.authorization.k8s.io

3. Subjects, Verbs, and Resources

Subjects are entities that represent entities such as users, groups, or service accounts. Verbs define actions such as “get,” “list,” and “delete,” while resources represent the Kubernetes entities on which these actions are performed.

Subjects:

Subjects are entities to which access is granted. They can be users, groups, or service accounts. RBAC bindings, whether roles or cluster roles, are associated with subjects to determine who gets access.

Verbs:

Verbs define the actions that subjects are permitted to carry out on resources. “Get,” “list,” “create,” “update,” and “delete” are examples of common verbs.

Resources:

Resources are the Kubernetes objects or entities on which actions are performed. They consist of pods, services, nodes, and other API objects.

Practical Example: Configuring RBAC for a Kubernetes Namespace

Step 1: Create a Namespace

kubectl create namespace tech-team

Here, we create a new namespace, tech-team, to house our development team’s resources and permissions.

Step 2: Create a Service Account

kubectl create serviceaccount dev-user -n tech-team

A service account, ‘dev-user,’ is established within the ‘tech-team‘ namespace. This service account will represent the entity requesting resource access.

Step 3: Create a Role

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

A Role named ‘pod-reader‘ is defined in this step, with permissions to perform ‘get’ and ‘list’ actions on pods in the ‘tech-team‘ namespace. Create a role that allows you to list and get pods in the tech-team namespace.

Apply the role:

kubectl apply -f role.yaml

Step 4: Create a RoleBinding

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: tech-team
subjects:
- kind: ServiceAccount
  name: dev-user
  namespace: tech-team
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

A RoleBinding name ‘read-pods‘ is created, which associates the ‘pod-reader‘ Role with the ‘dev-user‘ ServiceAccount within the ‘tech-team‘ namespace. Create a RoleBinding to link the Role to the ServiceAccount.

Apply the RoleBinding:

kubectl apply -f rolebinding.yaml

Step 5: Verify Permissions

Verify that the dev-user service account has the necessary permissions.

kubectl config set-context --current --namespace=tech-team

kubectl run test-pod --image=nginx --serviceaccount=dev-user

kubectl get pods

Switching to the tech-team’ namespace, we run a test pod using the ‘dev-user’ service account. The ‘get pods’ command verifies that the ‘dev-user’ service account has the necessary permissions to list and get pods within the ‘tech-team’ namespace.

Conclusion

In Kubernetes, role-based access control is a powerful tool for ensuring that your cluster remains secure and that your resources are only accessed by those who need them. You can tailor access policies to meet the specific needs of your applications and teams by understanding its components and adhering to best practices.

In this guide, we have looked into the complexities of RBAC, delving into its components and providing a step-by-step implementation example. You are now better prepared to navigate the complexities of access management within your Kubernetes environment.

Incorporating RBAC best practices as you build and scale your Kubernetes infrastructure will contribute to a secure, organized, and efficiently managed cluster.