Kubernetes Operator RBAC Risks: What OperTraitor Found in OperatorHub

Kubernetes operators can turn routine cluster management into automated work, but their service accounts may carry permissions far beyond the task at hand. That creates a practical security problem: if an operator is compromised, its access can expose resources across the cluster. OperTraitor, an open source analysis tool from Palo Alto Networks, is designed to help teams spot that gap between an operator’s documented purpose and its actual permissions.

The project’s findings point to two connected sources of risk: broad role based access control (RBAC) grants and outdated components that remain easy to deploy. Those concerns matter for traditional operators today and could become more consequential as teams experiment with autonomous systems that use large language models (LLMs) to manage clusters.

What OperTraitor checks

A Kubernetes operator combines a custom resource definition (CRD), which extends the Kubernetes API, with a controller that watches for changes and acts to bring the cluster toward a desired state. That automation runs under a service account. RBAC rules determine what the account can read or change, and therefore set the potential reach of a compromised operator.

OperTraitor analyzes raw RBAC configurations from operators installed locally and from the OperatorHub catalog. It compares granted permissions with the functionality described in operator documentation, then assigns a normalized risk score from 1 to 10 based on the difference. The project’s purpose is to make those permissions easier to inspect and compare before deployment.

The analysis focuses on the service account, whether an operator uses conventional controller logic or adds LLM based reasoning. AI can change how an operator decides what to do, but it doesn’t change the reach granted by RBAC. If an automated system can act independently, excessive access can give a mistaken or manipulated action a wider impact.

Old packages remain an exposure

The research also found that OperatorHub can surface abandoned or overly permissive components. Some vendors make newer operator versions available through Helm charts, GitHub repositories or ArtifactHub, while older versions remain available through the Operator Lifecycle Manager (OLM). Since OLM has been widely used, including in OpenShift environments, teams may deploy an older package through a familiar workflow without realizing that a newer version is distributed elsewhere.

The researchers say vendors often don’t maintain or retire these older entries. They identified multiple operators—slightly more than 5% in their research—with excessive permissions, including indirect paths to cluster administrator access. Some owners didn’t respond to disclosure attempts, which the researchers say can indicate that a component is no longer actively maintained.

That makes package age and maintenance status part of the security review. A familiar catalog entry doesn’t establish that a component is current, actively maintained or narrowly scoped. Teams need to check the version they’re installing and examine its RBAC requirements directly.

Two operators, two permission challenges

Prometurbo illustrates how a permission that looks routine in a manifest can create cluster wide exposure. OperTraitor flagged wildcards in the OperatorHub listing, which the researchers identified as version 8.6.0 from 2022. They then examined version 8.17.6 in IBM’s GitHub repository.

In that version, the operator’s service account was bound to a ClusterRole with permission to get, list and watch Secrets in the core API group. The grant applied across the cluster, rather than being limited to the operator’s namespace. Unless an operator is intended to manage secrets centrally, the research argues, it will generally need access only to particular secrets in a specific namespace.

Cluster wide read access could expose service account tokens, database credentials, API keys and TLS certificates stored in other namespaces if the operator were compromised. IBM responded to the disclosure, identified the cause and issued a patch that scoped the permissions more narrowly. The company also published a security bulletin and assigned CVE-2026-6389, with a High CVSS score of 8.8 out of 10.

The Datadog operator presented a different problem: its permissions included cluster wide access to secrets and actions on ClusterRoles and ClusterRoleBindings. Datadog explained that users define the names of the secrets the operator needs, so those names can’t be specified in advance. That design constraint can make narrowly enumerated permissions harder to deliver.

After disclosure, Datadog added documentation explaining its RBAC settings and the mitigations applied. That gives users information to assess the trade off and decide whether the access fits their environment. The case shows why permission reviews need context: broad access deserves scrutiny, while the reason for a grant and the available mitigations also matter.

What teams should take from the findings

Operator permissions deserve the same level of attention as access assigned to human administrators. Before deployment, teams can compare an operator’s documented job with its service account rules, look for wildcards and cluster wide access, and check whether the package is still maintained. Where an operator needs broad access for a specific design reason, documentation should make that reason and any mitigations clear.

When the permissions exceed what the workload needs, narrowing the service account is a direct way to reduce the damage a compromised component could cause. The research doesn’t provide a single permissions template for every operator: requirements depend on what the software manages and how its users configure it. That puts the burden on teams to review each component in context.

OperTraitor makes that review more systematic by turning RBAC configurations into a comparison and risk score. The score can help teams prioritize investigation, but the underlying rules and operator purpose still need human review. Its findings suggest that convenient installation paths and automatic cluster management can hide access decisions with meaningful consequences.

As operators gain more autonomy, teams will need a clear account of what each service account can reach and why. Reducing unnecessary permissions now gives both conventional controllers and future AI driven automation a smaller scope for mistakes or misuse.