Skip to main content

RBAC Configuration

Overview​

The OpsWorker Kubernetes Agent uses Kubernetes RBAC to define what it can access. The Helm chart does not ship a custom ClusterRole with an explicit rules block. Instead, it creates a ClusterRoleBinding that binds the agent's ServiceAccount to the Kubernetes built-in view ClusterRole.

Default Permissions​

The relevant chart values are:

rbac:
  create: true       # create the ClusterRoleBinding
  clusterRole: view  # bind to the built-in "view" role
serviceAccount:
  name: opsworker-agent

The built-in view ClusterRole is read-only across most namespaced resources (pods, services, deployments, events, ingresses, configmaps, and so on). It is the only RBAC the agent gets out of the box.

What the built-in view role does NOT grant​

  • Secret values - the view role does not allow reading Secret data. Secret access is opt-in and disabled by default (the kubernetes-mcp-server subchart ships a commented-out secrets-viewer binding). Enable it deliberately if you accept the risk.
  • Pod exec - no pods/exec. The agent never opens shells in your workloads.
  • Any write verbs - no create, update, patch, or delete.

rbac.create and rbac.clusterRole are the only RBAC knobs the chart exposes.

Namespace-Scoped Access​

The chart does not have a supported toggle to scope the agent to specific namespaces. If you need namespace scoping, you must hand-roll Role/RoleBinding resources and disable the cluster-wide binding.

  1. Install with --set rbac.create=false so the chart does not create the ClusterRoleBinding.
  2. Create a Role and RoleBinding in each namespace the agent should access. You can bind to the built-in view ClusterRole from a namespaced RoleBinding:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: opsworker-agent-view
  namespace: production  # repeat for each namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
  - kind: ServiceAccount
    name: opsworker-agent
    namespace: opsworker-agent

Repeat the RoleBinding in each namespace you want the agent to read. This is a manual workaround, not a chart feature.

Auditing Agent Access​

Check what the agent can access cluster-wide:

kubectl auth can-i --list \
  --as=system:serviceaccount:opsworker-agent:opsworker-agent

Check access to a specific namespace:

kubectl auth can-i get pods \
  -n production \
  --as=system:serviceaccount:opsworker-agent:opsworker-agent

Next Steps​