Kubernetes operators are privileged identities. Audit the controller before trusting the workload.

Unit 42 found that Kubernetes operators can carry excessive RBAC permissions that turn trusted automation into a high-impact non-human identity. Its OperTraitor research identified multiple operators with excessive privileges, including implicit paths to cluster-admin access. The practical issue is not configuration hygiene: unused or overly broad controller authority becomes latent attack surface.

Operators continuously reconcile desired state through service accounts bound to Roles or ClusterRoles. If a controller is compromised, its blast radius is defined by those permissions. Security reviews that focus on application workloads while treating operators as infrastructure plumbing can therefore miss one of the cluster's most consequential identities.

Audit granted RBAC against documented function

OperTraitor ingests operator RBAC and compares granted privileges with the functionality described by the operator. That gap is the useful control point. Wildcards, cluster-scoped access and permissions unrelated to the controller's documented job should trigger review rather than being accepted as installation defaults.

Platform teams should inventory production operators and inspect their Role and ClusterRole rules before deployment. Require an owner and rationale for wildcard verbs, cluster-wide scope and sensitive-resource access. Unit 42 specifically recommends continuously auditing and downscoping RBAC where architecture permits.

An operator's RBAC should describe what its controller must do, not everything its maintainers might someday want it to do.

Treat operator upgrades as privilege changes

Controller code and installation manifests change over time, and so can requested permissions. That makes an operator upgrade a security-sensitive identity change rather than a routine image refresh. Diff ClusterRoles and bindings during admission or CI, and flag newly introduced verbs, resources, wildcard scopes and secret access before rollout.

The IBM Prometurbo case shows why this matters. Unit 42 found cluster-wide read access to secrets in the operator's ClusterRole; IBM subsequently patched the issue and CVE-2026-6389 received IBM's CVSS 3.1 base score of 8.8. The Datadog case also showed broad permissions can arise from legitimate architectural trade-offs, which makes explicit risk acceptance important.

Monitor the controller as a privileged identity

Least privilege is only one layer. Unit 42 recommends monitoring Kubernetes Audit Logs and baselining normal operator service-account behaviour. Unexpected secret enumeration, access outside normal namespaces or API activity from unusual locations should be treated as identity anomalies, not merely application telemetry.

For production clusters, bring operators into the same governance cycle used for privileged human access: verify maintained sources, prefer namespace scope where possible, review effective permissions, inspect changes at upgrade time and monitor service-account behaviour. Autonomous infrastructure deserves identity governance proportional to the authority it carries.

Publication note, 4 October 2026: This article was produced and published through Devence Lab's automated workflow as an owner-requested publisher test. It is awaiting the owner's review.

Written by the Devence Lab research team.