DevOps Bootcamp · Lesson

Role-Based Access Control (RBAC)

Manage user and service account permissions within your cluster using RBAC roles and role bindings.

Role-Based Access Control (RBAC) is a free DevOps Bootcamp lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the DevOps Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What is RBAC in Kubernetes?

Welcome! In this lesson, we'll dive into Role-Based Access Control (RBAC), a crucial security feature in Kubernetes.

RBAC helps you manage who can do what within your cluster. It's like a bouncer for your Kubernetes resources, ensuring only authorized users and applications can perform specific actions.

Why RBAC is Essential

Without RBAC, anyone with cluster access could potentially perform any action, leading to security risks or accidental damage.

Security: Prevents unauthorized access and operations.
Compliance: Helps meet regulatory requirements for access control.
Least Privilege: Ensures users and applications only have the permissions they absolutely need.

Key RBAC Concepts

RBAC in Kubernetes relies on a few core components:

Subjects: The 'who' (users, service accounts, groups).
Roles: The 'what' (a set of permissions).
RoleBindings: The 'how' (links a Role to a Subject).
ClusterRoles & ClusterRoleBindings: Cluster-wide versions of Roles and RoleBindings.

Subjects: Users and Service Accounts

Kubernetes needs to know who is requesting an action. These are called Subjects:

Users: Typically human administrators or developers. Kubernetes doesn't manage users directly; it relies on external authentication.
Service Accounts: Kubernetes objects used by applications or processes running inside pods. These are crucial for pod-to-API server communication.

Defining Permissions with Roles

A Role defines a set of permissions within a specific namespace. It specifies what actions (verbs) can be performed on which resources.

For example, a Role might allow 'getting' and 'listing' pods in the 'default' namespace.

Role Example: Pod Reader

Here's a YAML definition for a Role named pod-reader. This Role grants permission to 'get', 'list', and 'watch' (monitor) pods.

Notice apiGroups: [""] which refers to the core Kubernetes API group.

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

Granting Permissions with RoleBindings

A RoleBinding connects a specific Role to one or more Subjects (users, service accounts, or groups) within a specific namespace.

It's the link that says, 'This user/app can do what this Role allows in this namespace.'

RoleBinding Example: Granting Access

This RoleBinding links our pod-reader Role to a Service Account named my-app-sa in the default namespace. Now, my-app-sa can read pods.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: my-app-sa # The service account getting permissions
  namespace: default
roleRef:
  kind: Role
  name: pod-reader # The Role being granted
  apiGroup: rbac.authorization.k8s.io

ClusterRoles and ClusterRoleBindings

Sometimes, you need permissions that apply across the entire cluster, not just one namespace. That's where ClusterRoles and ClusterRoleBindings come in.

ClusterRole: Defines permissions for cluster-scoped resources (like nodes, persistent volumes) or for actions across all namespaces (e.g., 'list all pods').
ClusterRoleBinding: Links a ClusterRole to Subjects, granting cluster-wide permissions.

RBAC Quick Check

A developer needs to deploy new applications only in the dev namespace. Which two Kubernetes RBAC resources would you primarily use to grant them this specific permission?

Recap: RBAC Fundamentals

Great job! You've learned the core of Kubernetes RBAC:

RBAC controls who can interact with your cluster resources.
Roles define permissions within a namespace.
RoleBindings link Roles to Subjects (users, service accounts).
ClusterRoles and ClusterRoleBindings handle cluster-wide permissions.

Mastering RBAC is key to securing your Kubernetes environment!

Frequently asked questions

Is the “Role-Based Access Control (RBAC)” lesson free?

Yes — the full text of “Role-Based Access Control (RBAC)” is free to read here on the web, and the DevOps Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the DevOps Bootcamp course, upgrade to CoddyKit PRO.

What will I learn in “Role-Based Access Control (RBAC)”?

Manage user and service account permissions within your cluster using RBAC roles and role bindings. You practise DevOps Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start DevOps Bootcamp?

No prior experience is required. DevOps Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Role-Based Access Control (RBAC)” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this DevOps Bootcamp lesson?

Yes. Every DevOps Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to DevOps Bootcamp