KubeWatchDocs
Start free

Capability Management

See which RBAC capabilities your Kubernetes agent has, toggle them on or off, and optionally let KubeWatch manage the underlying grants for you.

The Capabilities table on the Settings page lists every optional RBAC permission your KubeWatch agent can use (pod exec, secrets viewing, workload editing, and so on), whether it's currently granted on your cluster, and a switch to turn its use on or off. The table itself is Kubernetes-only, since Docker has no RBAC concept. Docker's equivalents are handled per capability instead: a Docker container exec toggle sits directly above the table on this same page (on by default, no Helm command and no Kubernetes involved at all, since it talks to the Docker Engine API directly), while others, like Cluster & Host Backups, are opt-in through an agent environment variable.

KubeWatch's backend can never grant itself a Kubernetes permission it doesn't already have. That's a deliberate security boundary, not a limitation we're working around. Every capability still needs your cluster's own consent at some point, either through a one-time Helm command, or through a small, narrowly-scoped controller you install yourself. There is nothing to configure to switch between the two: it's a fact about whether that controller is actually running, detected automatically. See "How grants actually happen" below for exactly what it does and doesn't let KubeWatch do.

The default: one Helm command per capability

Every capability starts as a one-time Helm command:

helm upgrade kubewatch-agent ... --set rbac.allowExec=true

Once a capability is granted this way, the toggle next to it becomes a real, instant on/off switch. Disabling it stops KubeWatch from ever dispatching that class of action again, immediately, with no further Helm command needed. Re-enabling it is instant too, as long as the underlying grant is still present on the cluster. Revoking the grant itself (removing it from the cluster entirely) still requires another Helm command with the flag set back to false.

kubewatch-rbac-controller

Every capability can additionally be managed live, with no Helm command after one initial install:

--set rbac.managementMode=automatic --set rbacController.enabled=true

New Kubernetes installs from the dashboard's onboarding wizard set both of these by default, so live toggling works out of the box. On a cluster older than 1.30, both flags are safely ignored at install time (see below) and you get the one-Helm-command-per-capability experience above instead, with nothing breaking and nothing needing to be removed. If you installed via a different route (the README quick start, an existing upgrade, or a self-hosted deployment), add both flags yourself with the command above to opt in.

Once that Deployment is up and reporting in, every capability's toggle becomes usable immediately, even before it's granted: flipping it on creates the underlying grant within seconds, no Helm command and no restart. There is no separate setting to flip in the dashboard for this. Whether a capability behaves this way is purely a live fact about whether the controller is actually running right now, not a stored preference. A customer who never sets rbacController.enabled=true keeps the exact original copy-paste-Helm-command experience for every capability, with nothing to configure. If the controller is later removed or crashes, every capability's toggle reverts to that same experience automatically.

This requires **Kubernetes 1.30 or later** (it relies on `ValidatingAdmissionPolicy`, a native Kubernetes API, GA since 1.30, not a third-party dependency). On an older cluster, stick with the one-Helm- command-per-capability default.

How grants actually happen

kubewatch-rbac-controller is a second, separately-privileged component, not the agent itself. Kubernetes' own rules block any component from granting itself a permission it doesn't already hold, so there's no safe way for the agent to expand its own access. Instead:

  • One fixed, predefined Kubernetes ClusterRole per capability is created once by the Helm chart and never changes.
  • The controller's only job is creating or deleting a ClusterRoleBinding that attaches your agent's identity to one of those predefined roles, based on what's toggled on in the dashboard.
  • The controller's own permissions are scoped so it can only ever reference those specific roles, and only ever grant them to your real agent's identity, enforced by Kubernetes itself, not application code. A fully compromised controller could not grant anything beyond the capabilities already defined in the chart, and could not grant them to anything other than your own agent.

Status while the controller is working

A toggle you just flipped may briefly show:

  • Enabling… / Disabling…: the controller hasn't reconciled yet (normally a few seconds).
  • Couldn't apply: the controller tried and Kubernetes rejected it. Check the controller's logs.
  • Controller unavailable: nothing has changed in over two minutes, meaning kubewatch-rbac-controller likely isn't running (or has just stopped reporting in). Confirm rbacController.enabled=true was actually set and the pod is healthy. The toggle for that capability locks again (greyed out, with the copy-paste Helm command still shown alongside it) until either the controller comes back or you grant it that way instead.