RBAC & security model

The agent installs into its own namespace and binds to a ClusterRole scoped to read-only verbs. It requests no create, update, patch, or delete permissions on your workloads, and it does not register as an admission or mutating webhook. You can review the exact chart and RBAC manifest before you install.

# The agent requests read-only verbs only.
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["get", "list", "watch"]

Illustrative

This is the shape of the ClusterRole, not a verbatim copy of the shipped manifest. The authoritative version is the one in the chart you install — read it with helm show templates runtimez/agent before applying.

What this rules out

• No mutation. No verb in the role can change cluster state.
• No webhook. The agent is not in the admission path, so it cannot block or alter a deployment even by accident.
• No Secret values. Secret objects fall under the read verbs, but the agent does not read or transmit their data; the same applies to ConfigMap values and container environment variables.
• No application data. Database contents, application logs, and in-memory data are out of scope entirely.

Verify it yourself

kubectl get clusterrole runtimez-agent -o yaml
kubectl auth can-i --list --as=system:serviceaccount:runtimez:runtimez-agent

The second command enumerates the effective permissions of the agent’s ServiceAccount as the API server sees them — which is the answer that actually counts, independent of what the chart claims.