Qingular

RBAC Access Control

·CKAk8s练习

RBAC (Role-Based Access Control) is Kubernetes' authorization mechanism for managing access to cluster resources.

← Back to CKA Practice Index

Overview

RBAC (Role-Based Access Control) is the core authorization mechanism in Kubernetes. It controls access to cluster resources for users or ServiceAccounts by defining Roles and RoleBindings. RBAC is mandatory content in the CKA exam.


Core Concepts

1. ServiceAccount

ServiceAccounts provide an identity for processes running in Pods, used for API Server authentication.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-sa
  namespace: default
# Create a ServiceAccount
kubectl create serviceaccount my-sa

# View ServiceAccounts
kubectl get serviceaccounts
kubectl describe sa my-sa

# View the ServiceAccount's Secret (auto-created)
kubectl get secrets | grep my-sa

2. Role vs ClusterRole

FeatureRoleClusterRole
ScopeSpecific NamespaceEntire cluster
Authorizable ResourcesNamespace-scoped resourcesCluster-scoped resources + namespace-scoped resources
Use CaseFine-grained namespace permissionsCluster-level management permissions

Role Example:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
# Create a Role
kubectl create role pod-reader --verb=get,list,watch --resource=pods
kubectl create role pod-reader --verb=get,list,watch --resource=pods --namespace=default

# View Roles
kubectl get roles --all-namespaces
kubectl describe role pod-reader -n default

ClusterRole Example:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "namespaces"]
  verbs: ["get", "list", "watch", "create", "delete"]
# Create a ClusterRole
kubectl create clusterrole node-admin --verb=get,list,watch --resource=nodes

# View ClusterRoles
kubectl get clusterroles
kubectl describe clusterrole cluster-admin

3. RoleBinding vs ClusterRoleBinding

FeatureRoleBindingClusterRoleBinding
ScopeSpecific NamespaceEntire cluster
Bind TargetRole or ClusterRoleClusterRole only
Bindable SubjectsUser, Group, ServiceAccountUser, Group, ServiceAccount

RoleBinding Example:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: ServiceAccount
  name: my-sa
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
# Create a RoleBinding
kubectl create rolebinding read-pods --role=pod-reader --serviceaccount=default:my-sa
kubectl create rolebinding read-pods --clusterrole=view --serviceaccount=default:my-sa -n default

# View RoleBindings
kubectl get rolebindings --all-namespaces
kubectl describe rolebinding read-pods -n default

ClusterRoleBinding Example:

# Create a ClusterRoleBinding
kubectl create clusterrolebinding my-admin --clusterrole=cluster-admin --user=admin-user

# View ClusterRoleBindings
kubectl get clusterrolebindings
kubectl describe clusterrolebinding my-admin

4. RBAC Verbs

VerbMeaningUse Case
getRead a single resourceQuery Pod details
listList a collection of resourcesList all Pods
watchWatch resource changesReal-time resource monitoring
createCreate resourcesCreate a Deployment
updateUpdate resourcesUpdate replica count
patchPartial updateAdd labels/annotations
deleteDelete resourcesDelete a Pod
deletecollectionBatch deleteDelete all Pods

5. Common RBAC Command Quick Reference

# --- Role Operations ---
kubectl create role <name> --verb=<verbs> --resource=<resources> [-n <namespace>]
kubectl get roles [-n <namespace>]
kubectl describe role <name> [-n <namespace>]
kubectl delete role <name> [-n <namespace>]

# --- ClusterRole Operations ---
kubectl create clusterrole <name> --verb=<verbs> --resource=<resources>
kubectl get clusterroles
kubectl describe clusterrole <name>
kubectl delete clusterrole <name>

# --- RoleBinding Operations ---
kubectl create rolebinding <name> --role=<role-name> --user=<user> [--serviceaccount=<sa>] [-n <namespace>]
kubectl create rolebinding <name> --clusterrole=<clusterrole-name> --user=<user> [-n <namespace>]
kubectl get rolebindings [-n <namespace>]

# --- ClusterRoleBinding Operations ---
kubectl create clusterrolebinding <name> --clusterrole=<clusterrole-name> --user=<user>
kubectl get clusterrolebindings

# --- Batch Operation Combination Examples ---
# Create a read-only user
kubectl create serviceaccount readonly-sa
kubectl create rolebinding readonly-binding --clusterrole=view --serviceaccount=default:readonly-sa

# Create a user that can manage Pods (limited to the default namespace)
kubectl create role pod-manager --verb=get,list,watch,create,update,delete --resource=pods
kubectl create rolebinding pod-manager-binding --role=pod-manager --serviceaccount=default:ops-sa

6. Verifying Permissions

# Check if the current user has a specific permission
kubectl auth can-i get pods
kubectl auth can-i create deployments

# Check another user's permissions
kubectl auth can-i get pods --as system:serviceaccount:default:my-sa

# Check all operation permissions
kubectl auth can-i --list
kubectl auth can-i --list --as system:serviceaccount:default:my-sa

# Check permissions in a specific namespace
kubectl auth can-i get pods -n kube-system --as system:serviceaccount:default:my-sa

7. Built-in ClusterRoles

Kubernetes provides four built-in ClusterRoles:

ClusterRoleDescription
cluster-adminSuper administrator, has all permissions
adminNamespace administrator, allows read/write of most resources
editAllows read/write of resources (excluding RBAC and quotas)
viewRead-only permissions (excluding Secrets)
# Grant read-only permissions to a user
kubectl create clusterrolebinding view-binding --clusterrole=view --user=dev-user

# Grant admin permissions to a ServiceAccount
kubectl create rolebinding sa-admin --clusterrole=admin --serviceaccount=default:app-sa

8. Subjects Field Details

The subjects field in RoleBinding and ClusterRoleBinding supports three types:

kindPurposeExample
UserKubernetes username: "john"
GroupUser groupname: "developers"
ServiceAccountPod identityname: "my-sa", namespace: "default"

CKA Exam Key Points

  1. Fast creation commands: Master the syntax of kubectl create role/clusterrole/rolebinding/clusterrolebinding
  2. Resource configuration rules: Role + ClusterRoleBinding = important pattern for cross-namespace permissions
  3. ServiceAccount auto-mounting: The default ServiceAccount is automatically created in every Namespace
  4. Principle of least privilege: In the exam, make sure to grant only the minimum necessary permissions
  5. Verification: Use kubectl auth can-i to quickly verify that permissions are correct

🧪 Complete Hands-On Example: Create Restricted RBAC Permissions for an Application Team

Scenario

In namespace team-a, create a ServiceAccount ci-bot and grant it permissions to only create and view Pods and Deployments, with deletion prohibited.

Prerequisites

  • A running Kubernetes cluster
  • A kubectl user with cluster-admin privileges

Steps

Step 1: Create namespace

kubectl create namespace team-a
# namespace/team-a created

Step 2: Create ServiceAccount

kubectl create serviceaccount ci-bot -n team-a
# serviceaccount/ci-bot created

# Verify
kubectl get sa ci-bot -n team-a
# NAME     SECRETS   AGE
# ci-bot   1         5s

Step 3: Create Role (grant create/get/list/watch permissions for Pods and Deployments)

kubectl create role ci-bot-role -n team-a \
  --verb=get,list,watch,create \
  --resource=pods,deployments
# role.rbac.authorization.k8s.io/ci-bot-role created

# Verify Role details
kubectl describe role ci-bot-role -n team-a

Step 4: Create RoleBinding to bind SA to Role

kubectl create rolebinding ci-bot-binding -n team-a \
  --role=ci-bot-role \
  --serviceaccount=team-a:ci-bot
# rolebinding.rbac.authorization.k8s.io/ci-bot-binding created

Step 5: Verify permissions (auth can-i)

# Verify allowed operations
kubectl auth can-i get pods -n team-a --as system:serviceaccount:team-a:ci-bot
# yes

kubectl auth can-i create deployments -n team-a --as system:serviceaccount:team-a:ci-bot
# yes

# Verify prohibited operations (delete is not authorized)
kubectl auth can-i delete pods -n team-a --as system:serviceaccount:team-a:ci-bot
# no

kubectl auth can-i delete deployments -n team-a --as system:serviceaccount:team-a:ci-bot
# no

Step 6: Actually use the SA's token to verify (optional)

# Get SA token
TOKEN=$(kubectl create token ci-bot -n team-a)

# Test creating a Pod
kubectl run test-pod --image=nginx -n team-a --token=$TOKEN
# pod/test-pod created

# Test deleting a Pod (should fail)
kubectl delete pod test-pod -n team-a --token=$TOKEN
# Error from server (Forbidden): pods "test-pod" is forbidden: ... ci-bot" is forbidden

Verification

# Final permission list
kubectl auth can-i --list -n team-a --as system:serviceaccount:team-a:ci-bot

Exam Tips

  • In the CKA exam, prefer the imperative approach using kubectl create role and kubectl create rolebinding commands, which is faster than writing YAML
  • --as system:serviceaccount:<ns>:<sa-name> is the standard method for verifying SA permissions in the exam
  • Note that Roles are namespace-scoped and ClusterRoles are cluster-scoped — do not confuse them
  • Principle of least privilege: only grant the verbs and resources explicitly required by the question

Official Documentation