RBAC Deep Dive

In December 2023, a security researcher discovered that thousands of Kubernetes clusters on the public internet had exposed dashboards running with cluster-admin privileges. Attackers weren't exploiting vulnerabilities—they were using the default service account that Kubernetes automatically mounts into every pod, which often had more permissions than the application ever needed.

Your Task API doesn't need cluster-admin access. It doesn't need access to secrets across all namespaces. It needs exactly one thing: the ability to read its own ConfigMap. RBAC (Role-Based Access Control) lets you specify precisely that—and nothing more.

This lesson builds the RBAC foundation that protects your Task API from privilege escalation attacks. By the end, you'll understand why every production workload needs its own ServiceAccount, and you'll have the pattern to implement least privilege for any Kubernetes application.

---

What RBAC Actually Controls

Before creating RBAC resources, understand what you're protecting. Every Kubernetes API request goes through three checkpoints:

RBAC handles the second checkpoint. When your Task API pod tries to read a ConfigMap, RBAC answers: "Is this ServiceAccount allowed to get ConfigMaps in this namespace?"

---

The Four RBAC Building Blocks

RBAC uses four types of resources that work together:

---

Step 1: Create a Dedicated ServiceAccount

First, create a namespace for your Task API if it doesn't exist:

Output:

Now create a dedicated ServiceAccount. The critical setting is automountServiceAccountToken: false, which prevents Kubernetes from automatically mounting the token into your pods. Create task-api-sa.yaml:

Apply the ServiceAccount:

Output:

Why Disable Auto-Mounting?

By default, Kubernetes mounts a token into every pod at /var/run/secrets/kubernetes.io/serviceaccount/. This token grants API access. If your application doesn't need to call the Kubernetes API, mounting this token only creates attack surface.

Verify the setting:

Output:

---

Step 2: Define the Role (Minimum Required Permissions)

Your Task API needs to read its ConfigMap for configuration. It doesn't need to create, update, or delete ConfigMaps. It doesn't need access to Secrets. Define exactly that. Create task-api-role.yaml:

Apply the Role:

Output:

Understanding the Rules

Each rule has three components:

Available verbs:

Never Use Wildcards

Using "*" for apiGroups, resources, or verbs grants far more access than needed. Explicit lists are always safer:

---

Step 3: Create the RoleBinding

The RoleBinding connects your ServiceAccount to the Role. Create task-api-binding.yaml:

Apply the RoleBinding:

Output:

---

Step 4: Test RBAC with kubectl auth can-i

Before deploying your application, verify that permissions work as expected. The kubectl auth can-i command tests whether an action is allowed:

Test Allowed Operations

Output:

Output:

Test Denied Operations

Output:

Output:

Output:

The ServiceAccount can read ConfigMaps in its own namespace, but cannot create them, cannot access Secrets, and cannot access resources in other namespaces.

---

Role vs ClusterRole: The Decision Matrix

When should you use Role (namespace-scoped) versus ClusterRole (cluster-scoped)?

Key Principle: Prefer RoleBinding Over ClusterRoleBinding

Even when using a ClusterRole, you can bind it with a RoleBinding to limit scope to one namespace:

This pattern gives you reusable role definitions without cluster-wide access.

---

Deploying with the ServiceAccount

To use your ServiceAccount in a Deployment, specify it in the pod spec:

When the pod needs to access the Kubernetes API (for example, to read its ConfigMap), you must explicitly mount the token:

---

Debugging RBAC Issues

When you see "403 Forbidden" errors, use these commands to diagnose:

Check What Permissions a ServiceAccount Has

Output:

Describe RoleBinding to Verify Configuration

Output:

Common RBAC Mistakes

---

The Complete RBAC Pattern

Here's the complete set of resources in a single file for easy deployment. Create task-api-rbac-complete.yaml:

Apply everything:

Output:

---

Reflect on Your Skill

Test whether your cloud-security skill generates least-privilege RBAC:

1. Does your skill set automountServiceAccountToken: false by default? If not, pods get tokens they might not need.
2. Does your skill avoid wildcards in Role rules? Check for "*" in apiGroups, resources, or verbs.
3. Does your skill include the kubectl auth can-i verification step? Testing before deploying prevents production issues.

If you found gaps, update your skill with the patterns from this lesson. Your skill should now generate the three-resource pattern (ServiceAccount + Role + RoleBinding) with least privilege defaults.

---

Try With AI

Use your cloud-security skill to practice RBAC design for different scenarios.

Prompt 1:

What you're learning: This scenario requires cluster-wide read access, which means ClusterRole + ClusterRoleBinding. Notice how the decision matrix guides you from requirements to the correct resource types. The skill should explain why Role won't work here.

Prompt 2:

What you're learning: Debugging RBAC errors by analyzing rule definitions. Pods are in the core API group (empty string ""), not "apps". The skill should identify this mismatch and provide the corrected YAML.

Prompt 3:

What you're learning: Security review of RBAC rules. This rule grants full access to Secrets across all API groups, which violates least privilege. The skill should identify the wildcards as dangerous and suggest specific, minimal permissions instead.

Security Reminder

Always test RBAC changes with kubectl auth can-i before deploying. A misconfigured RoleBinding can grant more access than intended or block legitimate operations.