RBAC Authorization

Introduction

Authorization in Kubernetes is commonly handled by RBAC (Role-Based Access Control).

User: An employee (like "Jane").
Role: A Key Card with specific access rights (e.g., "Can enter the server room", "Can read documents").
RoleBinding: The act of Giving the Key Card to the employee.

RBAC matters because cluster access is not only about authentication. After identity is known, the system still needs to decide what actions that identity is allowed to perform.

In this lab, you will act as the Chief of Security:

Create a "Visitor Pass" (Role) that allows looking at things but not touching them.
Assign this pass to a user named jane.
Verify that Jane can look around but gets rejected if she tries to change anything.

Define the Role

First, we need to create the permission set. We want a "Read-Only" role. This role allows someone to list and get (read) Pods, but not create or delete them.

RBAC is Kubernetes authorization, not authentication. Authentication answers "Who are you?" Authorization answers "What are you allowed to do?" This lab focuses on the second question by defining explicit allowed actions, called verbs, on specific resource types.

Create a file named role.yaml:

nano role.yaml

Paste the following YAML. This definition creates a Role allowed to perform "get", "watch", and "list" actions on "pods".

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

Save and exit (Ctrl+X, Y, Enter).

Now, print ("apply") this card in the cluster:

kubectl apply -f role.yaml

Verify it exists:

kubectl get roles

You should see pod-reader.

Bind the Role

Now we have the card (pod-reader) and the employee (jane). But Jane doesn't have the card yet. We need a RoleBinding to connect them.

A Role by itself grants nothing until it is referenced by a binding. This separation is deliberate. It lets administrators define reusable permission bundles once and then attach them to different users, groups, or service accounts as needed.

Create a file named rolebinding.yaml:

nano rolebinding.yaml

Paste the following content. This says: "Bind the pod-reader role to the user jane".

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: User
    name: jane ## The employee
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader ## The key card
  apiGroup: rbac.authorization.k8s.io

Save and exit (Ctrl+X, Y, Enter).

Apply the binding:

kubectl apply -f rolebinding.yaml

You have now officially given Jane read-only access to the default namespace.

Verify Access

How do we test this? We don't need to log out and log in as Jane. Kubernetes lets us "impersonate" a user to test permissions using the --as flag.

This is a practical administration technique. Permission checks are much safer when you can simulate an identity before handing access to a real user or automation account. It helps you verify intent without creating unnecessary side effects in the cluster.

Let's verify that Jane can list pods:

kubectl auth can-i list pods --as jane

The output should be yes.

You can also check if she can get details of a specific pod:

kubectl auth can-i get pods --as jane

The output should also be yes.

This confirms the RoleBinding is working. The Key Card works on the door readers!

Verify Restrictions

Security is also about what you cannot do. Since Jane only has the pod-reader role, she should strictly be forbidden from making changes.

This is the principle of least privilege in action. Instead of granting broad access and hoping people behave carefully, you start with the minimum permissions needed for the task and expand only when there is a real operational need.

Check if Jane can create a pod:

kubectl auth can-i create pods --as jane

The output should be no.

Check if Jane can delete a pod:

kubectl auth can-i delete pods --as jane

The output should be no.

If Jane tries to run these commands for real, the API server would reject her request with a "Forbidden" error. This confirms your cluster is secure and follows the principle of Least Privilege.

Summary

In this lab, you secured your cluster using RBAC.

You successfully:

Created a Role ("Key Card") with limited read-only permissions.
Created a RoleBinding to give that card to user jane.
Verified that jane is allowed to look but not touch.

This is the foundation of multi-user security in Kubernetes. Never give full admin access to everyone!