OperTraitor Finds Kubernetes Operators With Cluster-Wide Secret Access and Admin Paths

OperTraitor, an open-source, LLM-powered engine that identifies Kubernetes operators whose RBAC (Role-Based Access Control) privileges exceed their documented operational requirements.

Research indicates that over 5% of assessed operators requested excessive permissions, including cluster-wide access to secrets and potential pathways to cluster-admin-level control.

Kubernetes operators automate application deployment, configuration, and lifecycle management through Custom Resource Definitions (CRDs) and persistent controllers.

To reconcile the desired and actual states, controllers operate with Kubernetes service accounts that are bound to Roles or ClusterRoles.

This non-human identity becomes a crucial security boundary; if an operator is compromised (due to a vulnerable dependency, malicious image, supply chain intrusion, or node takeover), an attacker inherits all permissions granted to the service account.

OperTraitor Audits Operator RBAC

OperTraitor ingests YAML manifests from locally installed operators and OperatorHub, extracts role-based access control configurations, and employs an LLM-based analysis workflow to compare an operator’s stated purpose with its actual privileges.

The tool assigns a normalized risk score from 1 to 10 based on the gap between necessary permissions and those actually granted.

Researchers have identified legacy content in the OperatorHub and the Operator Lifecycle Manager (OLM) ecosystem as a particular point of exposure.

Vendors may distribute newer, patched operators through Helm charts, GitHub repositories, or ArtifactHub, while older, more permissive versions remain available in default registries.

This could lead organizations to inadvertently deploy abandoned or outdated components that have broad RBAC rights through otherwise straightforward installation workflows.

One notable case involved IBM’s Prometurbo operator, used with Turbonomic. Unit 42 initially identified wildcard RBAC permissions in an outdated OperatorHub release and later reviewed a newer version from IBM’s GitHub repository.

The operator’s service account was connected to a ClusterRole that permitted get, list, and watch operations against Kubernetes secrets across the cluster’s core API group.

Such access could allow an attacker who compromises the operator to enumerate service account tokens, database credentials, API keys, and TLS certificates stored in unrelated namespaces.

IBM addressed the issue, issuing CVE-2026-6389, which was rated 8.8 on the CVSS scale. The vulnerability was reported on November 5, 2025; IBM confirmed the remediation on February 3, 2026, and published its security bulletin on April 24, 2026.

OperTraitor also flagged the Datadog operator for its cluster-wide secret access and permissions involving ClusterRoles and ClusterRoleBindings.

These RBAC resources are especially sensitive, as the ability to create, modify, or bind privileged roles can provide an indirect path to elevated cluster privileges.

Datadog told the researchers that dynamically user-defined secret names made it hard to apply restrictive, preconfigured permissions. The vendor subsequently documented the operator’s Kubernetes permissions and available mitigations, enabling customers to assess the risks and make informed deployment decisions.

Unit 42 warned that the issue will become more critical as organizations adopt LLM-enhanced and autonomous operators. An operator acting as an external AI-agent bridge or a full in-cluster agent runtime could transform excessive RBAC from a mere configuration flaw into autonomous access to sensitive Kubernetes resources.

Security teams should validate operator manifests before deployment, prefer maintained vendor distribution channels, scope operators to only the namespaces they manage, and avoid ClusterRoles unless necessary.

They should also continuously audit service account permissions and set up alerts for abnormal behavior, such as an operator unexpectedly listing secrets in unrelated namespaces or accessing the Kubernetes API from unrecognized addresses.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC