TECH **Kubernetes RBAC: Zero-Fluff, Hands-On Guide**

Kubernetes RBAC: Zero-Fluff, Hands-On Guide

(Roles, RoleBindings, ClusterRoles, ClusterRoleBindings)

1. What This Is & Why It Matters

RBAC (Role-Based Access Control) in Kubernetes is how you control who can do what in your cluster. Think of it like a security badge system in an office: - Roles define what actions are allowed (e.g., "read files," "open doors").
- RoleBindings assign those roles to who (users, service accounts, groups).
- ClusterRoles and ClusterRoleBindings do the same, but cluster-wide (not just in one namespace).

Why This Matters in Production

• Security: Without RBAC, anyone with kubectl access can delete pods, read secrets, or even take over the cluster.
• Compliance: Auditors (SOC2, HIPAA, GDPR) will ask: "Who has access to what?" RBAC answers that.
• Team Scaling: You don’t want devs accidentally deleting production databases. RBAC lets you restrict permissions per team (e.g., "Devs can only deploy to staging").
• Disaster Recovery: If a rogue script or compromised service account runs kubectl delete --all, RBAC can block it.

Real-World Scenario

You’re a DevOps engineer at a fintech startup. Your CI/CD pipeline deploys to production, but a junior dev accidentally merges a PR that deletes all pods in default. Without RBAC, the pipeline has full admin access—game over. With RBAC, you restrict the CI/CD service account to only deploy to production and nothing else.

2. Core Concepts & Components

3. Step-by-Step Hands-On: Restrict a CI/CD Service Account

Prerequisites

• A running Kubernetes cluster (Minikube, EKS, AKS, or GKE).
• kubectl configured to access the cluster.
• A namespace for testing (e.g., ci-cd).

Goal

Create a service account for CI/CD that can only deploy to ci-cd namespace and cannot touch anything else.

Step 1: Create a Namespace

kubectl create namespace ci-cd

Step 2: Create a Service Account

kubectl create serviceaccount ci-cd-sa -n ci-cd

Verify:

kubectl get serviceaccounts -n ci-cd

Output:

NAME       SECRETS   AGE
ci-cd-sa   1         5s
default    1         10s

Step 3: Define a Role (What the SA Can Do)

Create role.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: ci-cd
  name: ci-cd-deployer
rules:
- apiGroups: ["", "apps", "batch"]  # "" = core API group
  resources: ["pods", "deployments", "jobs", "services"]
  verbs: ["get", "list", "create", "update", "delete", "patch"]

Apply:

kubectl apply -f role.yaml

Step 4: Bind the Role to the Service Account

Create rolebinding.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-cd-deployer-binding
  namespace: ci-cd
subjects:
- kind: ServiceAccount
  name: ci-cd-sa
  namespace: ci-cd
roleRef:
  kind: Role
  name: ci-cd-deployer
  apiGroup: rbac.authorization.k8s.io

Apply:

kubectl apply -f rolebinding.yaml

Step 5: Test the Permissions

Get the service account token:

kubectl get secret -n ci-cd $(kubectl get serviceaccount ci-cd-sa -n ci-cd -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode

Save the token to a variable:

TOKEN=$(kubectl get secret -n ci-cd $(kubectl get serviceaccount ci-cd-sa -n ci-cd -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode)

Test access (should work):

kubectl --token=$TOKEN -n ci-cd get pods

Test access (should fail):

kubectl --token=$TOKEN -n default get pods

Output:

Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:ci-cd:ci-cd-sa" cannot list resource "pods" in API group "" in the namespace "default"

Step 6: (Optional) Grant Read-Only Access to All Namespaces

If CI/CD needs to read cluster-wide resources (e.g., nodes), create a ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ci-cd-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "namespaces"]
  verbs: ["get", "list"]

Bind it with a ClusterRoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ci-cd-reader-binding
subjects:
- kind: ServiceAccount
  name: ci-cd-sa
  namespace: ci-cd
roleRef:
  kind: ClusterRole
  name: ci-cd-reader
  apiGroup: rbac.authorization.k8s.io

Apply:

kubectl apply -f clusterrole.yaml -f clusterrolebinding.yaml

Test:

kubectl --token=$TOKEN get nodes

4. ? Production-Ready Best Practices

Security

• Least Privilege: Start with no permissions, then add only what’s needed.
• Avoid Wildcards: Never use resources: ["*"] or verbs: ["*"] in production.
• Service Accounts: Always create dedicated SAs for apps/CI/CD—never use default.
• Audit Logs: Enable Kubernetes audit logging to track who did what.
• Network Policies: Combine RBAC with NetworkPolicies to restrict pod-to-pod communication.

Cost Optimization

• RBAC doesn’t cost money, but misconfigured permissions can lead to breaches (which cost $$$).
• Use namespaces to isolate teams/projects (e.g., dev, staging, prod).

Reliability & Maintainability

• Naming Conventions:
• Roles: team-resource-verb (e.g., dev-pods-reader).
• RoleBindings: team-resource-verb-binding (e.g., dev-pods-reader-binding).
• Label Everything: Use labels like environment: prod to filter RBAC rules.
• Idempotency: Use kubectl apply (not create) so updates don’t fail.

Observability

• Monitor RBAC Changes: Use tools like kube-audit or Open Policy Agent (OPA) to alert on suspicious RBAC modifications.
• Check Permissions: Use kubectl auth can-i to verify access: bash kubectl auth can-i create pods --as=system:serviceaccount:ci-cd:ci-cd-sa -n ci-cd

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus (CKA, CKAD, CKS)

Typical Question Patterns

1. "Which RBAC resource is namespace-scoped?"
2. ✅ Role and RoleBinding.

3. ❌ ClusterRole and ClusterRoleBinding (cluster-wide).

4. "How do you grant a user read-only access to all pods in a namespace?"

5. Create a Role with verbs: ["get", "list"] and bind it with a RoleBinding.

6. "What’s the difference between a Role and a ClusterRole?"

7. Role = Namespace-scoped.

8. ClusterRole = Cluster-wide (e.g., nodes, namespaces).

9. "How do you check if a service account can delete pods?"
   bash
kubectl auth can-i delete pods --as=system:serviceaccount:namespace:sa-name

⚠️ Trap Distinctions

Scenario-Based Question

"You need to allow a CI/CD pipeline to deploy to staging but not production. How?"
- ✅ Answer:
- Create a Role in staging with verbs: ["create", "update", "delete"] on deployments.
- Bind it to the CI/CD ServiceAccount with a RoleBinding.
- Do not grant any permissions in production.

7. ? Hands-On Challenge

Challenge

A monitoring tool (Prometheus) needs to read all pods and nodes in the cluster but should not modify anything. Create the minimal RBAC setup for it.

Solution

1. ClusterRole (read-only for pods and nodes):
   ```yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
   name: prometheus-reader
   rules:
2. apiGroups: [""]
   resources: ["pods", "nodes"]
   verbs: ["get", "list", "watch"]
   ```
3. ClusterRoleBinding (bind to Prometheus SA):
   ```yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
   name: prometheus-reader-binding
   subjects:
4. kind: ServiceAccount
   name: prometheus
   namespace: monitoring
   roleRef:
   kind: ClusterRole
   name: prometheus-reader
   apiGroup: rbac.authorization.k8s.io
   ```
5. Apply:
   bash
kubectl apply -f prometheus-clusterrole.yaml -f prometheus-clusterrolebinding.yaml Why it works:
6. ClusterRole grants read-only access to pods and nodes cluster-wide.
7. ClusterRoleBinding assigns it to the Prometheus service account.
8. No delete or create permissions = safe.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. Kubernetes RBAC Official Docs – The definitive source.
2. Kubernetes Security Best Practices (CNCF) – Real-world security guidance.
3. Open Policy Agent (OPA) for Kubernetes – Advanced policy enforcement.
4. kubectl auth can-i Explained – How to test permissions.

Final Thought

RBAC is not optional in production. Start restrictive, then loosen permissions as needed. A single misconfigured ClusterRoleBinding can take down your entire cluster—test everything with kubectl auth can-i.

Now go lock down your cluster! ?