Why RBAC matters in Kubernetes - Why It Works

Introduction

Kubernetes controls access to its resources using RBAC, which stands for Role-Based Access Control. It helps keep your cluster safe by making sure only the right people or programs can do certain actions.

When you want to limit who can create or delete pods in your Kubernetes cluster.

When you need to give a developer permission to only view resources but not change them.

When you want to allow an automated system to update deployments but not access secrets.

When you want to prevent accidental or harmful changes by restricting permissions.

When you want to audit who did what by assigning clear roles and permissions.

Config File - rbac-role.yaml

rbac-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

This file creates a Role named pod-reader in the default namespace that allows reading pods only.

The RoleBinding connects the Role to a user named jane, giving her permission to get, watch, and list pods in that namespace.

Commands

This command applies the RBAC Role and RoleBinding to the cluster, setting up the permissions for user jane.

Terminal

kubectl apply -f rbac-role.yaml

Expected Output

role.rbac.authorization.k8s.io/pod-reader created

rolebinding.rbac.authorization.k8s.io/read-pods-binding created

This checks if user jane has permission to get pods in the default namespace, verifying the RoleBinding works.

Terminal

kubectl auth can-i get pods --as=jane -n default

Expected Output

yes

→

--as - Simulates the command as the specified user

→

-n - Specifies the namespace to check permissions in

This checks if user jane can delete pods, which she should not be able to do with the current Role.

Terminal

kubectl auth can-i delete pods --as=jane -n default

Expected Output

no

→

--as - Simulates the command as the specified user

→

-n - Specifies the namespace to check permissions in

Key Concept

If you remember nothing else from this pattern, remember: RBAC lets you control who can do what in your Kubernetes cluster to keep it safe and organized.

Common Mistakes

Not specifying the correct namespace in RoleBinding or commands

Permissions are namespace-scoped, so missing or wrong namespaces cause access denial or unexpected access.

Always specify the correct namespace when creating RoleBindings and when checking permissions.

Assigning overly broad permissions like admin roles to all users

This can lead to accidental or malicious changes that harm the cluster or leak data.

Grant only the minimum permissions needed for each user or service.

Forgetting to bind Roles to users or service accounts

Roles alone do nothing until they are bound to subjects, so users won't get the intended permissions.

Always create RoleBindings or ClusterRoleBindings to connect Roles to users or groups.

Summary

Create Roles to define what actions are allowed on Kubernetes resources.

Use RoleBindings to assign these Roles to specific users or groups in a namespace.

Verify permissions with kubectl auth can-i to ensure correct access control.