OperTraitors: How Kubernetes Operators Betray Your Security Posture

What it is

OperTraitor is an open-source tool from Unit 42 that feeds operator RBAC manifests to an LLM. It compares the permissions an operator holds with what its documentation says it does, and scores the gap from 1 to 10. It reads both locally installed operators and the OperatorHub catalog. The page does not give a repository URL or install steps.

How it works

The pipeline collects operators from OperatorHub and from the local cluster, extracts their raw YAML manifests, and passes the RBAC sections to an LLM prompted for threat analysis. The UI shows the count of high-risk operators and per-operator scores. The page does not describe the prompt, the model used, or false-positive rates.

Findings that matter for triage

• Prometurbo (IBM Turbonomic), CVE-2026-6389, CVSS 8.8. The OperatorHub copy is v8.6.0 from 2022 and was flagged for wildcards. The current GitHub release, v8.17.6, still bound the service account to a ClusterRole with get, list and watch on core-group secrets (apiGroups: [""]). A compromised operator could read service account tokens, database credentials, API keys and TLS certificates in every namespace. The page names no fixed version, only "a subsequent release". Timeline: reported 5 November 2025, IBM confirmed the fix 3 February 2026, bulletin and CVE published 24 April 2026.
• Datadog operator. Flagged for cluster-wide secret access and verbs on ClusterRoles and ClusterRoleBindings. Datadog said the secret names come from user-defined values, so they cannot be listed in advance. Unit 42 accepted this as valid. Datadog added documentation of its RBAC settings and mitigations rather than narrowing the permissions.
• Wider scan. Slightly over 5% of operators requested excessive privileges, including implicit paths to cluster admin. Unit 42 does not name them. Many maintainers did not answer disclosure, which Unit 42 reads as a sign the operators are unmaintained.
• Stale OperatorHub entries. Vendors often ship fixed versions only through Helm charts, GitHub or ArtifactHub, while old versions stay installable through OLM, the default on OpenShift.

What to do

1. Do not trust the OperatorHub or OLM version. Check the vendor's docs and install from the maintained Helm chart, ArtifactHub or official GitHub release.
2. Prefer namespace-scoped operators. Avoid ClusterRoles and ClusterRoleBindings unless required.
3. Review vendor manifests and downscope RBAC, starting with production clusters. Look first for cluster-wide secrets reads and for RBAC-resource verbs.
4. Enable Kubernetes audit logs and baseline each operator service account. Alert on an operator listing secrets in an unrelated namespace or calling the API server from an unexpected IP.
5. For LLM-enhanced or agentic operators (the page cites K8sGPT, MCP bridges and in-cluster agent runtimes), block public internet and unapproved internal egress with network policies, and limit the context and permissions passed to the LLM.

Caveats

The page gives no commands or detection queries. The score is LLM-derived and unvalidated in the text. The agentic-operator risk is Unit 42's forecast, not a demonstrated attack. The article also promotes Cortex Cloud and Unit 42 services.