how to scope an agent's kubectl RBAC to one namespace

TL;DR

Give the agent a dedicated ServiceAccount, a Role (not ClusterRole) limited to one namespace, and only the verbs it needs on only the resources it needs. Never hand an agent cluster-admin or a wildcard Role; the blast radius of an agent with broad RBAC is every namespace at machine speed. Start narrow, widen deliberately, and audit what it actually uses.

The query

how to scope an agent's kubectl RBAC to one namespace

Use this when

• An AI agent needs kubectl access
• Applying least privilege to automation identities
• Containing the blast radius of agent mistakes
• Auditing what an automation identity can do

Not for when

• Human user access (different trust model)
• Multi-namespace operators the agent legitimately needs
• Cloud IAM roles (separate system)

Steps

Step 1: Create a dedicated ServiceAccount for the agent

The agent gets its own ServiceAccount in the target namespace, not the default one and not a shared automation identity. Dedicated identity means the audit log shows exactly what the agent did. Expected output: a ServiceAccount whose entire purpose is this agent.

Step 2: Write a Role limited to the namespace and needed verbs

Define a namespaced Role granting only the verbs the agent needs (often get, list, and maybe create/delete on specific resources like pods or jobs). No wildcards on resources or verbs; enumerate them. If the agent only reads, it gets read-only. Expected output: a Role whose permissions you can read in one screen and justify line by line.

Step 3: Bind with a RoleBinding, never a ClusterRoleBinding

Bind the Role to the ServiceAccount with a RoleBinding in the same namespace. Double-check there is no ClusterRoleBinding granting this account anything cluster-wide; one stray binding silently escalates everything. Expected output: the agent's effective permissions confirmed as namespace-scoped via an auth check.

Step 4: Verify with can-i before handing over the credential

Run auth checks as the ServiceAccount for allowed and denied actions: it can list pods in its namespace, it cannot list namespaces, cannot touch other namespaces, cannot escalate. Test the denials, not just the allows. Expected output: allows pass, denials hold, documented.

Step 5: Audit and tighten periodically

Review the API audit log for what the agent actually used. Permissions it never touches get removed; new needs get added deliberately with a reason. Agent capabilities evolve; the Role should evolve with them, by review, not by drift. Expected output: a Role that matches the agent's real usage, reviewed on a schedule.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_11JQKGvUKagzcfY5ZZ1zJw