Based on research by Palo Alto Networks Unit 42.
Kubernetes operators make life easier for DevOps teams by automating complex tasks like managing databases, monitoring tools, and application lifecycles. But new research from Palo Alto Networks’ Unit 42 shows that these same operators often come with too many permissions, turning them into silent backdoors if compromised.
In this post, we break down what the research found, why it matters for teams using Kubernetes in Nepal, and what you can do to stay safe.
Over-privileged Kubernetes operators can become a serious entry point for attackers if they are compromised.
A Kubernetes operator is a custom controller that extends the Kubernetes API through Custom Resource Definitions (CRDs). It continuously compares an application’s actual state with its desired state and uses a service account with RBAC permissions to make changes inside the cluster. Operators are commonly used for databases, message queues, and monitoring tools such as Datadog. If an operator is compromised, the impact depends on the permissions assigned to its service account.
A common issue is that Kubernetes operators are given broad RBAC permissions so they can work without configuration problems. Some can access sensitive resources, including secrets, ClusterRoles, and ClusterRoleBindings across the entire cluster. If one of these operators is compromised, an attacker may gain far more access than the operator actually needs.
OperTraitors is an open-source tool created to identify risky Kubernetes operator permissions. It reviews RBAC configurations from installed operators and OperatorHub, then compares an operator’s intended function with the access it has been granted. The tool gives a risk score that can help security teams find operators that should have their permissions reduced.
OperTraitors identified excessive permissions in IBM Turbonomic’s Prometurbo agent. Affected versions 8.16.0 through 8.17.6 granted excessive cluster-wide permissions, including unrestricted read access to Kubernetes Secrets. If exploited, this access could expose sensitive information such as credentials, tokens, API keys, and certificates. IBM addressed the issue through its security process, and it was assigned CVE-2026-6389 with a CVSS score of 8.8 (High).
The Datadog Operator was also flagged because it had cluster-wide access to secrets and broad permissions for RBAC resources. Datadog explained that some permissions support flexible user configurations, since secret names can differ between deployments. To help organizations understand this trade-off, Datadog documented its RBAC design and the mitigations that users should consider.
Kubernetes is increasingly using AI-driven and agentic operators that can make decisions, automate remediation, and manage AI workloads. If these tools receive overly broad permissions, they can access sensitive information or modify cluster resources with limited human oversight. A small permission mistake can therefore create a much larger security risk when automation is involved.
Here are practical steps your team can take:
Use trusted sources, check maintenance status, and review documentation, RBAC permissions, and security advisories.
Limit operators to the namespaces and resources they need. Avoid cluster-wide roles unless absolutely necessary.
Remove unnecessary permissions and reassess access after upgrades or configuration changes. Tools such as OperTraitors can help identify excessive privileges.
Enable Kubernetes Audit Logs and alert on unusual behavior, such as unexpected access to secrets or API activity.
Restrict network access, limit the data shared with AI systems, and give their service accounts only the permissions they require.
As Nepali organizations use Kubernetes for fintech, e-commerce, SaaS, government, and enterprise projects, operator security will become more important. Teams may install open-source operators quickly without closely reviewing their permissions, especially if they do not have dedicated cloud-security staff. Reviewing RBAC settings, checking whether operators are maintained, and limiting access to only what is needed can reduce this risk.
Kubernetes environments require ongoing security oversight, particularly when they use third-party operators, privileged service accounts, and cluster-wide permissions. A small RBAC misconfiguration can significantly increase the impact of a compromised workload.
One Cover Nepal supports organizations through cybersecurity assessments, security consulting, managed security services, incident response, IT audits, and risk-management services. For cloud-native environments, we help organizations review access permissions, validate third-party components, monitor suspicious activity, and strengthen their overall security posture.
Kubernetes operators bring huge benefits, but they also introduce highly privileged, non-human identities into your cluster. The research from Unit 42 shows that:
Overprivileged operators are common
Some are outdated or abandoned but still easy to install
The shift to AI-driven agentic operators will make this risk even more serious
By improving RBAC hygiene today—verifying sources, scoping permissions, and monitoring behavior—teams can safely embrace automation and AI without compromising security.
Organizations using Kubernetes should include operator-permission reviews, third-party component validation, and service-account monitoring in their wider cloud-security and risk-management practices.
This post draws on Palo Alto Networks Unit 42’s September 2026 research into Kubernetes operator security risks.
Need help strengthening your organization’s cybersecurity posture?
Visit One Cover Nepal: onecovernepal.com