🔐 Kubernetes RBAC (Role-Based Access Control) – A Deep Dive¶

RBAC (Role-Based Access Control) is one of the most crucial topics in Kubernetes administration, especially for CKA certification. It controls who can do what in a Kubernetes cluster.

🧠 Table of Contents¶

1. What is RBAC?
2. Key Concepts
3. RBAC Resources
4. Types of Subjects
5. How Kubernetes Authenticates Users
6. Creating Roles and RoleBindings
7. Step 4: Understanding API Groups
8. Step 5: Understanding Subresources
9. ServiceAccount vs User vs Group
10. Tips for CKA and Practice Ideas

📘 What is RBAC?¶

RBAC (Role-Based Access Control) lets you control access to Kubernetes resources based on a user’s role (i.e., their job/responsibility). You define who can perform which actions on which resources.

Example: - Devs can read pods. - Admins can delete deployments. - A CI pipeline can create and update secrets.

🧩 Key Concepts¶

🧱 RBAC Resources¶

Kubernetes uses the following resources to implement RBAC:

• Role: Defines allowed actions within a namespace.
• RoleBinding: Grants access to a Role for a user/group/service account in a namespace.
• ClusterRole: Same as Role, but for cluster-wide use.
• ClusterRoleBinding: Grants access to a ClusterRole for subjects across the whole cluster.

🧓‍♂️ Types of Subjects¶

A Role/ClusterRole is applied to a subject, which can be of three types:

🔐 How Kubernetes Authenticates Users¶

Kubernetes does NOT manage users and groups internally.

It relies on external authentication systems: - ✅ TLS Certificates (self-signed or signed by a CA) - ✅ Cloud IAM (AWS IAM, Azure AD, GCP IAM) - ✅ OIDC (Google, Okta, etc.) - ✅ Webhooks (Custom user systems)

🧠 That's why you can use --user or --group in RoleBindings, even though you never created those inside the cluster!

🎯 Creating RBAC Rules – Examples¶

1. Create a Role¶

kubectl create role pod-reader \
  --verb=get --verb=list --verb=watch \
  --resource=pods

2. Create a RoleBinding¶

kubectl create rolebinding read-pods-binding \
  --role=pod-reader \
  --user=john@example.com \
  --namespace=dev

3. Using API Groups¶

kubectl create role foo \
  --verb=get,list,watch \
  --resource=rs.apps

4. Using SubResources¶

kubectl create role foo \
  --verb=get,list,watch \
  --resource=pods,pods/status

🔄 Step 4: Understanding API Groups¶

Kubernetes resources are split into API Groups:

To know the group for a resource:

kubectl api-resources

Example:

kubectl create role foo --verb=get --resource=deployments.apps

Format: --resource=resourceName.groupName

🔄 Step 5: Understanding Subresources¶

Some Kubernetes resources have subresources. These are attached to the main resource but represent a sub-functionality:

Format:

--resource=resource/subresource

--resource=resource.group/subresource

Example:

kubectl create role viewer --verb=get --resource=pods/status

Understanding --resource=resource.group/subresource¶

When using the --resource flag in kubectl create role, you're defining the exact API target the role will apply to. This flag can have three components:

• resource → The main Kubernetes object.
  Examples: pods, deployments, services

• group → The API group the resource belongs to.
  Examples: apps, batch, rbac.authorization.k8s.io

• subresource (optional) → A more specific part or action related to the resource.
  Examples:

• pods/log – to access logs from a pod
• deployments/scale – to allow scaling of deployments
• pods/status – to read or modify the status subresource of a pod

📌 Format:
--resource=resource.group/subresource
All three components are not always required. For core resources (like pods), the group may be empty. And subresource is only used when needed.

Examples:¶

# Targeting the core 'pods' resource
--resource=pods

# Targeting the 'replicasets' resource in the 'apps' API group
--resource=replicasets.apps

# Targeting the 'status' subresource of pods
--resource=pods/status

👤 ServiceAccount vs User vs Group¶

📆 Tips for CKA and Practice¶

• Use kubectl auth can-i to test permissions:

  kubectl auth can-i delete pods --as john@example.com
  

• Practice creating:

• Role and RoleBinding
• ClusterRole and ClusterRoleBinding
• With API group, subresources, and resource names

• For service accounts and users

• Use kubectl explain to dig into any resource:

  kubectl explain role
  

📦 Real-World Use Case: CI/CD Pipeline¶

You have a CI/CD tool running as a Pod with a ServiceAccount. You want it to only create/update deployments.

1. Create Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cicd-role
  namespace: dev
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create", "update"]

2. Create RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cicd-bind
  namespace: dev
subjects:
- kind: ServiceAccount
  name: cicd-sa
  namespace: dev
roleRef:
  kind: Role
  name: cicd-role
  apiGroup: rbac.authorization.k8s.io

🛠️ All Verbs Explained (with Real-Life Examples)¶

controlplane ~ ➜  k describe clusterrole cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
             [*]                []              [*]

🔍 kubectl describe clusterrole cluster-admin Explained¶

You ran:

kubectl describe clusterrole cluster-admin

And got this core info:

🧠 What This Means in Layman's Terms¶

Imagine Kubernetes is a city, and every API call is like accessing a building or facility (hospital, bank, etc.).

• 🧑‍⚖️ ClusterRole: cluster-admin = The Mayor + Police Chief + Super Admin — has full access to all buildings, all services, and all paths in the entire city (cluster).

🔐 Field-by-Field Breakdown¶

1. Resources: *.*¶

This means:

• * = All API groups (like core, apps, networking.k8s.io, etc.)
• * = All resources in those API groups (pods, services, secrets, etc.)

📦 Effect: "You can access every resource in the cluster regardless of API group."

2. Non-Resource URLs: [*]¶

These are URLs like:

• /healthz
• /metrics
• /api
• /version
• /logs

📦 Effect: "You can also call any non-resource endpoints that are outside the Kubernetes object model."

3. Resource Names: []¶

Empty means "applies to all objects".

Example:

• If this was [my-secret], it would only apply to one specific resource.
• But since it’s empty, it applies to all resource names of every kind.

4. Verbs: [*]¶

This means:

["get", "list", "watch", "create", "update", "patch", "delete", "deletecollection", "bind", "impersonate", ...]

📦 Effect: "You can do everything possible with any resource."

🛡️ Summary: Why This Role Is So Powerful¶

💥 cluster-admin has:

• All verbs
• On all resources
• Across all namespaces
• Including non-resource URLs

This is the equivalent of root on Linux.

✅ Where This Is Used¶

By default:

• The user who bootstraps the cluster (like kubeadm init) gets cluster-admin.
• You can assign this role using a ClusterRoleBinding.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-admin-binding
subjects:
- kind: User
  name: ibtisam
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io