Kubernetes RBAC: Roles, ClusterRoles and ServiceAccounts

Overview

Kubernetes RBAC (Role-Based Access Control) is the foundation of security in Kubernetes clusters. This tutorial covers creating and managing access policies through Roles, ClusterRoles, RoleBindings, and ServiceAccounts—essential knowledge for the Certified Kubernetes Administrator exam.

Prerequisites:

• Working Kubernetes cluster (1.19+)
• kubectl installed and configured
• Understanding of Kubernetes namespaces
• Basic YAML syntax knowledge

Why This Matters for CKA: RBAC questions appear in 10-15% of the exam. You'll need to quickly create Roles, bind them to ServiceAccounts, and troubleshoot permission issues. This tutorial focuses on practical, exam-relevant scenarios.

Getting Started

First, verify your cluster has RBAC enabled and check your current permissions:

kubectl api-resources | grep rbac
kubectl auth can-i get pods --as=system:serviceaccount:default:my-app

Create a test namespace for hands-on practice:

kubectl create namespace rbac-demo
kubectl config set-context --current --namespace=rbac-demo

Verify the ServiceAccount that exists by default in every namespace:

kubectl get serviceaccounts
kubectl get serviceaccount default -o yaml

Understanding ServiceAccounts

ServiceAccounts are Kubernetes identities used by pods to authenticate with the API server. Every pod uses a ServiceAccount (default if not specified).

Create a custom ServiceAccount:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: rbac-demo

Apply and verify:

kubectl apply -f serviceaccount.yaml
kubectl get sa my-app -o yaml

Notice the ServiceAccount is automatically linked to a Secret containing the API token. This token is mounted into pods at /var/run/secrets/kubernetes.io/serviceaccount/token.

Common Pitfall: New administrators often forget that the default ServiceAccount in the default namespace has no special permissions. Always create explicit ServiceAccounts for applications.

Creating and Managing Roles

Roles define permissions within a specific namespace. ClusterRoles are cluster-wide equivalents.

Create a Role that allows reading Pods and viewing logs:

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

Apply and verify the Role:

kubectl apply -f role.yaml
kubectl get roles -n rbac-demo
kubectl describe role pod-reader -n rbac-demo

Key Concepts:

• apiGroups: Empty string represents core API; use 'apps' for Deployments, 'batch' for Jobs
• resources: The objects you're granting access to (pods, services, deployments)
• verbs: Actions allowed (get, list, create, update, delete, patch, watch)
• resourceNames: Optional—restrict to specific resource instances

Create a more advanced Role with specific resource restrictions:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployment-manager
  namespace: rbac-demo
rules:
- apiGroups: ['apps']
  resources: ['deployments', 'replicasets']
  verbs: ['get', 'list', 'create', 'update', 'patch']
- apiGroups: ['']
  resources: ['pods']
  verbs: ['get', 'list']
- apiGroups: ['']
  resources: ['services']
  resourceNames: ['frontend']
  verbs: ['get', 'update']

RoleBindings and ClusterRoles

RoleBindings attach Roles to ServiceAccounts (or Users/Groups). Bind the pod-reader Role to the my-app ServiceAccount:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: rbac-demo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader
subjects:
- kind: ServiceAccount
  name: my-app
  namespace: rbac-demo

Apply and test permissions:

kubectl apply -f rolebinding.yaml
kubectl auth can-i get pods --as=system:serviceaccount:rbac-demo:my-app -n rbac-demo

ClusterRoles and ClusterRoleBindings work across all namespaces. Create a cluster-wide admin ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: log-reader
rules:
- apiGroups: ['']
  resources: ['pods', 'pods/log']
  verbs: ['get', 'list']
- apiGroups: ['']
  resources: ['namespaces']
  verbs: ['get', 'list']

Bind the ClusterRole across all namespaces:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: log-reader-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: log-reader
subjects:
- kind: ServiceAccount
  name: my-app
  namespace: rbac-demo

Best Practice: Always use the principle of least privilege. Grant only the permissions needed. Use Roles for namespace-scoped access and ClusterRoles only when truly necessary.

Practical Exam Scenarios

Scenario 1: A deployment needs to read ConfigMaps and Secrets in its namespace. Create the minimal RBAC setup:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-reader
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: config-reader
  namespace: default
rules:
- apiGroups: ['']
  resources: ['configmaps', 'secrets']
  verbs: ['get']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-config
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: config-reader
subjects:
- kind: ServiceAccount
  name: app-reader
  namespace: default

Test the permission and verify what's denied:

kubectl auth can-i get configmaps --as=system:serviceaccount:default:app-reader
kubectl auth can-i delete configmaps --as=system:serviceaccount:default:app-reader

Scenario 2: Grant a ServiceAccount permission to exec into pods for debugging:

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

Scenario 3: Create read-only access to cluster resources across all namespaces:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-reader
rules:
- apiGroups: ['']
  resources: ['pods', 'services', 'namespaces']
  verbs: ['get', 'list', 'watch']
- apiGroups: ['apps']
  resources: ['deployments', 'daemonsets', 'statefulsets']
  verbs: ['get', 'list', 'watch']

Exam Tips for Certified Kubernetes Administrator (CKA)

Key Concepts to Master:

• ServiceAccount = pod identity; every pod needs one
• Role = namespace-scoped permissions; ClusterRole = cluster-wide
• RoleBinding connects Role to ServiceAccount; ClusterRoleBinding connects ClusterRole
• Use kubectl auth can-i to test permissions quickly

Common Exam Questions:

• Create a Role allowing a user to create and delete Deployments in a namespace
• Bind a ClusterRole to a ServiceAccount across specific namespaces (requires multiple RoleBindings)
• Troubleshoot RBAC errors in pod logs (common: forbidden errors)
• Audit which permissions a ServiceAccount has

Quick Reference Commands:

kubectl auth can-i create deployments --as=system:serviceaccount:default:my-app -n default
kubectl get roles -A
kubectl get rolebindings -A
kubectl describe role pod-reader -n rbac-demo
kubectl delete rolebinding read-pods -n rbac-demo

Time-Saving Tips: Use kubectl create role and kubectl create rolebinding commands for quick generation, then edit YAML as needed:

kubectl create role pod-reader --verb=get,list --resource=pods -n rbac-demo --dry-run=client -o yaml
kubectl create rolebinding read-pods --role=pod-reader --serviceaccount=rbac-demo:my-app --dry-run=client -o yaml

Summary

Key Takeaways:

• ServiceAccounts are pod identities—create them explicitly for applications
• Roles define permissions in a namespace; ClusterRoles are cluster-wide
• RoleBindings connect Roles to ServiceAccounts; use ClusterRoleBindings for cluster-wide access
• Always apply least privilege—grant only necessary permissions
• Use kubectl auth can-i to validate RBAC configurations

Next Steps: Practice creating RBAC configurations in your test cluster. Work through the exam scenarios and focus on speed—CKA is time-constrained. Explore network policies and pod security policies for advanced security topics. Review the official Kubernetes RBAC documentation for comprehensive details on wildcard rules and advanced configurations.