Kubernetes RBAC: Introduction to Access Control

RBAC (Role-Based Access Control) is Kubernetes' native mechanism for managing who can do what in your cluster. As a beginner, understanding RBAC basics enables you to secure your initial deployments and prepares you for advanced concepts covered in CKA and CKS certifications.

TL;DR: RBAC works in two steps: (1) create a Role that lists permissions, (2) create a RoleBinding that assigns that Role to a user. Fundamental principle: always grant only the minimum privileges necessary.

This topic is covered in the Kubernetes Fundamentals training.

---

What is RBAC in Simple Terms?

RBAC stands for "Role-Based Access Control". It works like a badge system in a company: each badge grants access to certain rooms, not all of them.

In Kubernetes, RBAC answers three questions:

Remember: RBAC is enabled by default since Kubernetes 1.8. Verify with kubectl api-versions | grep rbac.

---

The Two Essential Objects: Role and RoleBinding

To get started, focus on just two objects:

1. The Role: Defining Permissions

A Role lists what is allowed in a specific namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev        # This Role applies only to the "dev" namespace
name: pod-reader      # Role name
rules:
- apiGroups: [""]       # "" = core API (pods, services, etc.)
resources: ["pods"]   # Targeted resources
verbs: ["get", "list", "watch"]  # Allowed actions

Common verbs:

• get: read a specific resource
• list: list all resources of a type
• watch: observe changes in real-time
• create, update, delete: modify resources

2. The RoleBinding: Assigning Permissions

A RoleBinding associates a Role with a user or group:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: alice-pod-reader
namespace: dev
subjects:
- kind: User
name: alice           # The user receiving the permissions
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader      # The Role to apply
apiGroup: rbac.authorization.k8s.io

Remember: A RoleBinding links ONE Role to ONE or more users in ONE namespace.

---

Practical Example: Restricting Access to Pods

Here's how to create read-only access to pods in the "dev" namespace:

# Step 1: Create the Role
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
EOF

# Step 2: Create the RoleBinding
kubectl create rolebinding alice-reader \
--role=pod-reader \
--user=alice \
--namespace=dev

# Step 3: Verify permissions
kubectl auth can-i list pods --namespace=dev --as=alice
# Expected result: yes

kubectl auth can-i delete pods --namespace=dev --as=alice
# Expected result: no

---

Why is RBAC Important for Security?

Without RBAC, all users would have access to everything. Here are the risks:

According to , IT teams spend 34 days per year resolving Kubernetes issues. Good RBAC configuration prevents many incidents.

---

Going Further

This page covers RBAC basics for the one-day training. For advanced cases:

Check out the LFS458 Kubernetes Administration training (4 days) to deepen these concepts and prepare for CKA certification.

---

Essential kubectl Commands for RBAC

# List Roles in a namespace
kubectl get roles -n dev

# List RoleBindings
kubectl get rolebindings -n dev

# View Role details
kubectl describe role pod-reader -n dev

# Test a user's permissions
kubectl auth can-i create pods --as=alice -n dev

# List ALL permissions for a user
kubectl auth can-i --list --as=alice -n dev

---

Take Action

You've discovered the basics of RBAC. To put it into practice:

1. Create a test namespace: kubectl create namespace rbac-test
2. Apply the examples from this page
3. Test with kubectl auth can-i to verify your configurations

The Kubernetes Fundamentals training includes a hands-on RBAC lab where you restrict access to sensitive data under the guidance of an expert instructor.

Contact our advisors to schedule your training.