Permissions & Trust

This page is the authoritative reference for the exact permissions the SRExpert Agent holds on your cluster. Every capability is listed — nothing is hidden, nothing is “just in case”.

Source of truth: the rules below mirror charts/srexpert-agent/templates/clusterrole.yaml (the Helm install path) and the YAML served at /api/v1/agent/install/{token} (the curl | kubectl apply path). Both are kept in sync.

Summary

The SRExpert Agent installs as a DaemonSet in the srexpert-system namespace with a ServiceAccount named srexpert-agent, bound to a single ClusterRole of the same name. Every permission below exists for a specific product capability, documented inline.

No wildcards. No privilege-escalation primitives. No built-in cluster-admin.

1. Read Cluster State (Read-Only)

Needed to populate the dashboard, show workloads, compute health, and run security scans.

Category	Resources	Verbs
Core objects	pods, nodes, namespaces, services, configmaps, secrets, endpoints, persistentvolumes, persistentvolumeclaims, serviceaccounts, resourcequotas, limitranges, replicationcontrollers, events	list, get, watch
Metrics API (`metrics.k8s.io`)	nodes, pods	list, get
Pod subresources	logs, exec, portforward, status, attach	get, create
Workloads (`apps/`)	deployments, statefulsets, daemonsets, replicasets	list, get, watch
Batch	jobs, cronjobs	list, get, watch
Networking (`networking.k8s.io`)	networkpolicies, ingresses	list, get, watch
Storage (`storage.k8s.io`)	storageclasses	list, get, watch
Autoscaling	horizontalpodautoscalers, verticalpodautoscalers	list, get, watch
Policy	poddisruptionbudgets	list, get, watch
CRDs (`apiextensions.k8s.io`)	customresourcedefinitions	list, get, watch
Admission (`admissionregistration.k8s.io`)	validating/mutating webhook configurations, admission policies	list, get, watch
Gatekeeper CRDs	constrainttemplates + all Gatekeeper constraint/config/status/mutations/expansion/externaldata/connection groups	list, get, watch

Pod subresources (logs, exec, portforward, attach) are only used when a user explicitly opens a log viewer, Terminal, or AI Terminal session in the SRExpert UI. The agent never initiates these on its own.

2. Changes You Explicitly Request

These verbs are only triggered when you click a button in the UI (Install chart, Apply policy, Scale deployment, etc.) or an approved background task runs. Every write is audited.

Category	Resources	Verbs
Workload changes	pods, namespaces, services, configmaps, secrets, endpoints, serviceaccounts, persistentvolumes, persistentvolumeclaims, resourcequotas, limitranges, replicationcontrollers, events	create, update, patch, delete, deletecollection
App lifecycle	deployments, statefulsets, daemonsets, replicasets, jobs, cronjobs	create, update, patch, delete, deletecollection
Network management	networkpolicies, ingresses	create, update, patch, delete
Autoscaling	horizontalpodautoscalers, verticalpodautoscalers	create, update, patch, delete
Policy	poddisruptionbudgets	create, update, patch, delete
CRDs	customresourcedefinitions	create, update, patch, delete
Admission webhooks	validating/mutating webhook configurations	create, update, patch, delete
RBAC	roles, rolebindings, clusterroles, clusterrolebindings	create, update, patch, delete
Gatekeeper	All Gatekeeper CRD groups listed above	full manage

Why does the agent need write access to RBAC and CRDs? Helm charts routinely create RBAC resources for the workloads they install and register their own CRDs. Installing Gatekeeper, cert-manager, or any modern operator via SRExpert requires these permissions.

3. Leader Election

Category	Resources	Verbs
Coordination (`coordination.k8s.io`)	leases	get, create, update

The agent can only touch the srexpert-agent-leader Lease used by its own DaemonSet’s leader election. It cannot read other Leases in the cluster.

What the Agent Cannot Do — By Design

Explicitly excluded. Verified with kubectl auth can-i:

kubectl auth can-i escalate clusterroles \
  --as=system:serviceaccount:srexpert-system:srexpert-agent
# Output: no

Capability	Status	Why
`escalate` verb on RBAC	❌ Denied	A compromised agent cannot write a new ClusterRole that gives it cluster-admin and bind to itself
`bind` verb on RBAC	❌ Denied	Cannot create RoleBindings that reference privileged ClusterRoles it is not already allowed to grant
Built-in `cluster-admin`	❌ Never	The ClusterRoleBinding points at the explicit `srexpert-agent` ClusterRole, never the built-in `cluster-admin`
Wildcard apiGroup / resource	❌ Never	No `apiGroups: ["*"]` rule. Custom CRDs from third-party operators are NOT readable unless their apiGroup is enumerated above
Control-plane objects	❌ No access	No access to componentstatuses, etcd, apiserver flags, or anything outside the apiGroups listed above
Node lifecycle actions	❌ Denied	Cannot drain, cordon, or delete nodes (nodes are read-only — no `update` or `delete` on `nodes`)
System namespaces	❌ Read-only	`kube-system`, `kube-public`, etc. — observed only through the read verbs above, never modified

What This Means for Trust

Minimum necessary — the ClusterRole is a positive allow-list. Adding a new capability to SRExpert requires adding a specific rule, reviewable in git history.
Auditable — every action the agent takes goes through the srexpert-agent ServiceAccount. Kubernetes audit logs attribute every call unambiguously.
Revocable — kubectl delete namespace srexpert-system removes every permission listed above. No leftover ClusterRole binding to unknown resources.
Open source — the agent and its Helm chart are public. You can read the ClusterRole template yourself before installing.
Hardened runtime — the agent pod runs with readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, runAsNonRoot: true, and all Linux capabilities dropped.

Verifying the Permissions Yourself

After installing the agent, you can audit exactly what its ServiceAccount is allowed to do:

# List every verb/resource pair the agent can perform
kubectl auth can-i --list \
  --as=system:serviceaccount:srexpert-system:srexpert-agent
 
# Check a specific permission
kubectl auth can-i delete nodes \
  --as=system:serviceaccount:srexpert-system:srexpert-agent
# Expected: no
 
kubectl auth can-i list pods --all-namespaces \
  --as=system:serviceaccount:srexpert-system:srexpert-agent
# Expected: yes

Cluster Footprint

Everything the agent owns on your cluster:

1 Namespace — srexpert-system
1 ServiceAccount — srexpert-agent (in srexpert-system)
1 ClusterRole — srexpert-agent (the allow-list above)
1 ClusterRoleBinding — srexpert-agent → ServiceAccount srexpert-agent
1 Secret — srexpert-agent-secret (holds the registration token)
1 ConfigMap — srexpert-agent-config (backend URL + tuning knobs)
1 DaemonSet — srexpert-agent (one pod per node, leader-elected)

Nothing else.

History

Date	Event
2026-04-20	ClusterRole narrowed to the explicit allow-list above. Wildcard and privilege-escalation primitives removed. The install YAML served by the backend now matches the Helm chart.
Pre-2026-04-20	Agent ran with cluster-admin via the served YAML. Helm chart already used a narrower role but the `curl

Agent Overview — What the agent is and how it works
Add Cluster — Install the agent
security.txt — Report security issues

Overview Security Overview