New OperTraitors Tool Reveals Dangerous Privilege Escalation Paths in Kubernetes Operators

A new open-source security tool, OperTraitor, has revealed how Kubernetes operators can create dangerous privilege escalation paths when they receive excessive role-based access control permissions.

The tool analyzes operator manifests and compares their documented function with the permissions actually granted to their service accounts.

Kubernetes operators automate administrative tasks such as deploying databases, monitoring workloads, and managing infrastructure resources. They use custom resource definitions and controllers to continuously compare a cluster’s desired state with its real state.

To do this, operators need Kubernetes service accounts with RBAC permissions. 1qHowever, many operators are given broad permissions for convenience.

In some cases, developers use wildcard permissions or cluster-wide ClusterRoles rather than restricting access to the namespaces and resources an operator genuinely needs.

If an attacker compromises such an operator through a vulnerable container image, dependency flaw, or supply-chain attack, those permissions can turn a limited breach into a cluster-wide incident.

OperTraitors Tool

OperTraitor, released by Palo Alto Networks, examines RBAC YAML manifests from locally installed Kubernetes operators and the OperatorHub catalog.

It uses an LLM-powered analysis engine to identify differences between an operator’s stated purpose and its actual privileges. The tool then assigns a normalized risk score from 1 to 10, helping defenders identify operators that may need reduced RBAC permissions.

The research found that more than 5% of examined operators requested excessive permissions, including potential paths to cluster administrator access.

The issue is especially concerning for older or abandoned operators still available through OperatorHub and the Operator Lifecycle Manager.

While vendors may publish newer versions through Helm charts, GitHub, or ArtifactHub, outdated releases can remain available in default registries and may still be deployed by users.

One case involved IBM’s Prometurbo operator, used with IBM Turbonomic. OperTraitor identified that the operator had cluster-wide permission to get, list, and watch Kubernetes Secrets.

This meant a compromised operator could potentially access sensitive data from unrelated namespaces, including service account tokens, database credentials, API keys, and TLS certificates.

IBM fixed the issue after responsible disclosure, assigning CVE-2026-6389 a CVSS 8.8 High severity rating and reducing the operator’s permissions to better follow least-privilege principles.

OperTraitor also flagged the Datadog operator for broad access to Secrets and RBAC resources such as ClusterRoles and ClusterRoleBindings.

Datadog said some permissions were needed because users can define secret names dynamically, making them difficult to restrict in advance. The vendor published documentation explaining its permissions and available mitigations, allowing customers to assess the risk.

The findings highlight growing risks as Kubernetes adopts LLM-enhanced and agentic operators, which can make autonomous decisions, call external services, and manage agent lifecycles; excessive RBAC privileges could expose sensitive cluster data or enable unintended actions at scale.

Security teams should review every operator’s service account, avoid deploying outdated registry packages, and favor namespace-scoped Roles over cluster-wide ClusterRoles wherever possible.

Monitoring Kubernetes audit logs can also help identify unusual behavior, such as an operator attempting to read Secrets from unrelated namespaces.

OperTraitor gives defenders a way to detect risky non-human identities before they become a path to full Kubernetes cluster compromise.

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