RBAC: Securing Your Agent Deployments

In Chapter 5, you deployed a Kubernetes Pod with a containerized agent. By default, that Pod can read any ConfigMap, access any Secret, create Pods, delete Deployments—anything in the cluster. This is a security disaster. If an attacker compromises your agent container, they inherit all those permissions and can pivot through your entire cluster.

Role-Based Access Control (RBAC) solves this by restricting what your agent can do. Instead of giving your agent all permissions, you define exactly which Kubernetes resources it needs to access and which verbs (actions) it can perform on those resources. Your agent can read the ConfigMap it needs but cannot delete Deployments. Another agent can list Pods but cannot create Secrets. This is the principle of least privilege: each workload gets only the permissions it needs, nothing more.

---

Security Requirement: Agent Access Control

Before configuring RBAC, define what your agent needs:

Why this matters: A compromised agent cannot become a stepping stone to cluster-wide compromise.

---

RBAC Components

RBAC consists of five components. Understanding how they connect is critical:

---

Creating a ServiceAccount

A ServiceAccount is your Pod's identity. When your Pod makes a request to the Kubernetes API, it presents its ServiceAccount token.

Output:

Verify it was created:

Output:

Notice Kubernetes automatically created a token secret (agent-sa-token-xyz789). This token is what your Pod will use when making API requests.

---

Defining a Role with Minimal Permissions

A Role specifies what actions are allowed. For your agent, it only needs to read ConfigMaps and Secrets:

Save this as agent-role.yaml and apply it:

Output:

Verify the Role was created:

Output:

Understanding the Rule:

• apiGroups: [""]: Empty string means the core API group where ConfigMaps and Secrets live.
• resources: ["configmaps", "secrets"]: Explicitly defines the objects the agent can access.
• verbs: ["get", "list"]: The agent can retrieve specific objects (get) and enumerate all in the namespace (list). It cannot create, delete, or modify.

---

Binding the Role to the ServiceAccount

A Role defines permissions, but it's not assigned to anyone yet. A RoleBinding connects the ServiceAccount (your agent's identity) to the Role (the permissions):

Save this as agent-rolebinding.yaml and apply it:

Output:

Verify the RoleBinding was created:

Output:

What happened: The RoleBinding now says "ServiceAccount agent-sa in namespace default gets the permissions from Role agent-reader in namespace default."

---

Assigning ServiceAccount to Your Pod

Your Pod must explicitly use the ServiceAccount you created. When you create a Pod without specifying a serviceAccountName, it uses the default ServiceAccount, which has no permissions. To use your agent-sa:

When this Pod starts, Kubernetes mounts the agent-sa token into the container at /var/run/secrets/kubernetes.io/serviceaccount/token. Your agent can then use this token to authenticate API requests.

Apply the Pod:

Output:

---

Auditing Permissions with kubectl auth can-i

How do you verify your agent actually has the permissions you defined? Use kubectl auth can-i:

Output:

The agent can get configmaps. Now test if it can delete deployments (it shouldn't):

Output:

Correct. The agent cannot delete deployments because the agent-reader Role doesn't include the delete verb for deployments.

Test accessing secrets:

Output:

Test creating pods (it shouldn't):

Output:

Good—the agent is restricted. It can only get and list configmaps and secrets, nothing else.

---

Principle of Least Privilege

The approach above demonstrates least privilege: the agent gets exactly the permissions it needs and nothing more. Compare two scenarios:

---

Try With AI

Setup: You're designing RBAC for a multi-tenant AI deployment. Multiple agents run in the same cluster but in different namespaces:

• Namespace "agents-team-a": Agent needs ConfigMap "config-a" and Secret "creds-a" (team-a namespace only)
• Namespace "agents-team-b": Agent needs ConfigMap "config-b" and Secret "creds-b" (team-b namespace only)
• Both agents need to read the Deployment object to check the current replica count (list, get verbs only)

Task 1: Design the RBAC structure

Ask AI: "Design RBAC for a multi-tenant Kubernetes deployment. I have two teams, each in their own namespace. Each team's agent needs:

1. Read-only access to its own namespace's ConfigMap and Secret (by name: config-a/config-b and creds-a/creds-b).
2. Ability to list and get Deployments in its own namespace only.
3. No cross-namespace access. Show me the ServiceAccount, Role, and RoleBinding YAML for team-a. How would team-b's setup differ?"

Task 2: Audit the permissions

Ask AI: "After applying the RBAC, how would I use kubectl auth can-i to verify that the team-a agent can:

• Get its own ConfigMap but not team-b's?
• Get Deployments but not create Deployments?
• Not access secrets in other namespaces? Show me the exact kubectl commands and expected outputs."

Task 3: Refine for production

Ask AI: "What additional RBAC considerations should I include for production? Should I use more granular resource restrictions, API groups, or non-resource URLs? Show me an enhanced Role that adds read-only access to Pod logs and metrics."

Expected Outcomes:

• You understand how ServiceAccounts, Roles, and RoleBindings compose to restrict permissions.
• You can design RBAC that enforces least privilege across namespaces.
• You can audit what an agent can and cannot do using kubectl auth can-i.
• You recognize that over-permissioning is a common security anti-pattern.

---

Reflect on Your Skill

You built a kubernetes-deployment skill in Chapter 0. Test and improve it based on what you learned.

Test Your Skill

Identify Gaps

Ask yourself:

• Did my skill include the principle of least privilege (only necessary permissions)?
• Did it explain the RBAC component hierarchy (ServiceAccount → RoleBinding → Role → Resources)?
• Did it cover kubectl auth can-i for auditing permissions?
• Did it distinguish between Role/RoleBinding (namespace-scoped) and ClusterRole/ClusterRoleBinding (cluster-scoped)?

Improve Your Skill

If you found gaps: