Agent Role-Based Access Control (RBAC)

A Subject is the entity (user, service account, or group) that requests access to perform an action. In agent systems, subjects are typically:

• Service Accounts: Non-human identities assigned to an agent pod or deployment for authenticating to the Kubernetes API.
• Users: Human operators or administrators.
• Groups: A collection of users or service accounts, simplifying policy management.

For example, an invoice-processor-agent would have a dedicated service account subject like system:serviceaccount:agents:invoice-processor.

A Role or ClusterRole defines a set of permissions (rules) within a namespace or cluster-wide, respectively.

• Role: Namespace-scoped. Grants permissions to resources (e.g., pods, configmaps) only within its namespace.
• ClusterRole: Cluster-scoped. Can grant permissions to cluster-scoped resources (e.g., nodes, persistentvolumes) or be used across all namespaces.

Each rule within a Role specifies:

• API Groups (e.g., ", "apps")
• Resources (e.g., "pods", "services")
• Verbs (e.g., "get", "list", "create", "delete")

Example Role for a monitoring agent: allows get and list on pods and services in the monitoring namespace.

A RoleBinding or ClusterRoleBinding grants the permissions defined in a Role/ClusterRole to a Subject.

• RoleBinding: Binds a Role to Subjects within a specific namespace. The subjects and the referenced Role must exist in the same namespace.
• ClusterRoleBinding: Binds a ClusterRole to Subjects cluster-wide, granting permissions across all namespaces.

This is the critical link that enforces the principle of least privilege. For instance, a RoleBinding named monitoring-agent-access in the production namespace binds the pod-reader Role to the monitoring-agent service account, granting it read-only pod access solely within production.

Resources are the Kubernetes API objects (e.g., pods, deployments, secrets, services) that agents need to access.

API Verbs are the actions a subject can perform on those resources. Core verbs include:

• get: Retrieve a specific resource.
• list: List all resources of a type.
• watch: Stream events for resources.
• create: Instantiate a new resource.
• update / patch: Modify an existing resource.
• delete: Remove a resource.

A Role's rule apiGroups: [""], resources: ["pods"], verbs: ["get", "list", "watch"] allows an agent to monitor pods but not create or delete them.

A Service Account provides a distinct identity for processes (like agents) running in a Pod to interact with the Kubernetes API server. It is a namespaced resource.

Key functions:

• Authentication: The service account token is mounted into the pod, allowing the kubelet to authenticate API requests on behalf of the agent.
• Authorization Basis: Service accounts are the primary subjects referenced in RoleBindings for agents.
• Least Privilege Enforcement: By creating a unique service account per agent or agent type, permissions can be finely scoped.

An agent pod's spec includes serviceAccountName: task-allocator-agent. The associated RoleBinding grants this account only the permissions necessary for task allocation.

Namespaces are virtual clusters within a physical Kubernetes cluster, providing a scope for resource names and a critical boundary for RBAC.

Impact on Agent RBAC:

• Role & RoleBinding Scope: These objects are namespace-scoped, naturally isolating agent permissions to their designated environment (e.g., dev, staging, production).
• Multi-Tenancy: Different agent teams or applications can be deployed in separate namespaces with isolated, namespace-specific RBAC policies.
• ClusterRole Flexibility: A ClusterRole can be bound within a specific namespace using a RoleBinding, or cluster-wide using a ClusterRoleBinding.

Example: An agent in the data-processing namespace cannot access resources in the payments namespace unless explicitly granted a ClusterRole or a RoleBinding in that other namespace.

The overarching discipline encompassing all authentication, authorization, network policies, and communication security measures specific to a multi-agent system.

• Components: Includes Agent RBAC, Pod Security Standards, Network Policies (controlling pod-to-pod traffic), and mutual TLS (mTLS) for service mesh communication.
• Defense-in-Depth: RBAC is a critical authorization layer, but it operates alongside other controls. For instance, a Network Policy can block an agent from contacting a database even if its RBAC role permits it, providing a secondary security boundary.
• Goal: To create a zero-trust architecture where agents operate with minimal necessary privileges, all communication is encrypted and authenticated, and actions are fully auditable.

The unintended divergence of an agent's running configuration from its declared, desired state in version-controlled manifests. This is a key risk that RBAC and other controls help mitigate.

• Causes: Manual ad-hoc changes (kubectl edit), inconsistent updates, or compromised agents altering their own runtime parameters.
• RBAC as Prevention: Strict RBAC policies can prevent agents or users from modifying critical resources (Deployments, ConfigMaps) that define agent configuration, locking changes to a GitOps workflow.
• Detection & Correction: Tools like Kubernetes operators use reconciliation loops to constantly compare actual state with desired state and correct drift. Effective RBAC ensures only the operator's service account has the permissions needed to perform these corrective actions.