TL;DR: 70% of organisations use Kubernetes, while 50% run at least one unsupported cluster version and 93% have overprivileged service accounts, according to Orca Security’s 2025 cloud security report, showing that runtime Kubernetes risk is still driven by lifecycle and access governance gaps. Source context links production findings back to Helm code origins, which matters because remediation speed and ownership now depend on tracing identity and configuration drift to the source.
At a glance
What this is: This is a Kubernetes security analysis showing that unsupported cluster versions and overprivileged service accounts remain widespread, and that tracing runtime resources back to Helm source can speed remediation.
Why it matters: It matters because Kubernetes issues are often governance and ownership problems as much as technical ones, and IAM, PAM, and cloud security teams need source-level traceability to contain blast radius and assign remediation correctly.
By the numbers:
- 70% of organizations now use Kubernetes in their cloud environments.
- 50% of organizations using Kubernetes run at least one unsupported cluster version.
- 93% have overprivileged service accounts.
Context
Kubernetes security problems often begin long before a cluster reaches production. When clusters, pods, secrets, and config maps are defined through Helm, the runtime state inherits whatever versioning, ownership, and privilege choices were embedded in the chart and its templates.
That makes source traceability a governance issue as much as a technical one. If teams cannot connect a running workload back to its Helm origin, they struggle to identify who owns remediation, how far a misconfiguration has spread, and whether the same template is repeating the same risk across environments.
The Kubernetes risk pattern in this article is typical rather than exceptional. Widespread adoption combined with unsupported versions and overprivileged service accounts means the control gap is not visibility alone, but the inability to connect live exposure to the code and configuration that created it.
Key questions
Q: What breaks when Kubernetes resources cannot be traced back to their Helm source?
A: Teams lose the ability to assign ownership, determine blast radius, and see whether a runtime issue is isolated or repeated across many deployments. In practice, remediation slows because the security finding lacks a source artifact that a developer can act on. Cloud-to-dev traceability turns an ambiguous runtime alert into a fixable code issue.
Q: Why do excessive service account privileges create such a serious risk in Kubernetes clusters?
A: Excessive service account privileges increase risk because they turn a single pod compromise into a cluster-wide control problem. If an attacker can reuse mounted tokens or access preinstalled accounts with RBAC powers, they can modify roles, deploy new pods, and expand access beyond the original foothold. That is why least privilege and tight token exposure matter.
Q: What are the signs that a Kubernetes programme is losing governance control?
A: Unsupported versions, repeated template-driven misconfigurations, and service accounts that carry broad permissions all indicate that the programme is drifting away from governable state. When the same Helm artefact keeps producing the same exposure, governance is failing at the source rather than at the point of detection.
Q: Should teams prioritise Helm template review or runtime detection first?
A: Teams need both, but source review becomes the higher-leverage control when the same chart or template is reused broadly. Runtime detection finds the exposure, while template review stops it from reappearing in the next deployment. The right sequencing is to contain what is live and fix the reusable source that created it.
Technical breakdown
Why Helm source traceability changes Kubernetes security operations
Helm is a packaging and templating layer for Kubernetes that turns reusable YAML definitions into deployed resources. That efficiency creates an identity and configuration problem: the same chart or template can generate many workloads, secrets, and service accounts across clusters, so a runtime finding is rarely a one-off. Source traceability closes the gap between the deployed object and the definition that created it, which is what allows teams to determine whether a risk is isolated, systemic, or inherited from a shared template.
Practical implication: map runtime findings back to chart, template, file, and owner data before assigning remediation.
Why overprivileged service accounts remain the main escalation path
In Kubernetes, service accounts give workloads an identity for API access. When those identities carry excess permissions, an attacker who reaches a pod, token, or mounted secret can often move from a small foothold to broader cluster access. The article’s 93% figure shows how common this is. The real issue is not just account count, but permission scope that outlives the workload’s actual need. That is a classic privilege problem in workload identity form.
Practical implication: review service account permissions against workload function, not against deployment convenience.
How unsupported cluster versions widen the attack surface
Unsupported Kubernetes versions matter because they fall outside vendor maintenance, so known weaknesses, compatibility gaps, and insecure defaults can persist without a clear remediation path. In practice, an unsupported cluster also complicates accountability: teams may delay fixes because the platform itself no longer provides a clean upgrade target. That creates a layered problem where runtime exposure, patch uncertainty, and configuration drift reinforce each other across the estate.
Practical implication: track unsupported clusters as lifecycle debt, not just as patch backlog.
Threat narrative
Attacker objective: The attacker wants to turn a local Kubernetes foothold into broader cluster control by abusing workload identity and repeated template-driven exposure.
- Entry begins when a workload or attacker reaches Kubernetes through an overprivileged service account, exposed secret, or misconfigured pod.
- Credential access or privilege abuse follows when the compromised identity can use cluster APIs beyond its intended scope.
- Escalation and lateral movement occur as the same permissions enable access to additional pods, secrets, or namespaces across reused Helm deployments.
- Impact is the ability to exfiltrate data, alter cluster state, or disrupt workloads at scale through a single templated misconfiguration.
Breaches seen in the wild
- Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cloud-to-dev traceability is now a Kubernetes governance control, not just an operational convenience. When runtime resources cannot be traced back to the chart, template, file, and owner that created them, remediation becomes a guessing exercise. That breaks the accountability model that Kubernetes governance depends on, especially in environments where the same Helm artifact can fan out across many deployments. Practitioners should treat source linkage as part of control ownership, not a reporting enhancement.
Overprivileged service accounts remain the most practical path from workload compromise to cluster-wide impact. Kubernetes service accounts are workload identities, and their permissions should be scoped to the task at hand. When those permissions are broad, every compromised pod, secret, or token becomes an escalation candidate. The 93% overprivileged figure shows that this is not an edge case but a common operating condition, so blast-radius control has to start with identity scope, not with incident response.
Unsupported cluster versions represent lifecycle debt that compounds identity risk. A cluster that no longer receives standard support weakens the organisation’s ability to keep the control plane, workloads, and access policies aligned. That is not simply a patching issue. It is a signal that the Kubernetes programme has drifted away from a governable state, and teams should treat unsupported versions as evidence that lifecycle controls are failing to keep pace with deployment velocity.
Helm has created a templated risk multiplier across Kubernetes estates. A single chart or template can reproduce the same misconfiguration and the same overprivileged identity pattern many times over. That means the unit of governance is no longer the individual workload alone but the source artefact that generates it. Practitioners should rethink review, ownership, and remediation around reusable templates, because that is where repeatable risk is manufactured.
Source-of-truth visibility is becoming the decisive control for Kubernetes remediation. Once a running workload can be tied to its repository, chart, and code owner, teams can collapse the gap between detection and action. That changes Kubernetes security from an environment-wide hunting problem into an ownership problem that can be resolved faster and with less ambiguity. The organisations that cannot make that connection will continue to absorb the same configuration failures repeatedly.
From our research library:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- Read next: Kubernetes NHI Security Guide
What this signals
Identity scope, not just cluster hygiene, is the central Kubernetes governance issue. Service accounts are workload identities, and when they are overprivileged the blast radius is determined by access scope rather than by where the workload happens to run. That makes Kubernetes a cross-functional IAM, cloud security, and platform operations problem, not a siloed container issue.
Cloud-to-dev tracing exposes the Kubernetes source-of-risk loop: runtime exposure, reusable templates, and ownership gaps reinforce each other until the same misconfiguration appears in multiple places. Security teams should expect remediation to accelerate only when chart provenance and code ownership are part of the investigation from the start.
Organisations that cannot connect a live workload back to its chart and owner will keep treating symptoms instead of sources. That is why Kubernetes security programmes need lifecycle discipline around templated deployment artefacts, not just monitoring after deployment.
For practitioners
- Trace runtime findings back to chart origins Require every high-risk Kubernetes finding to be linked to its Helm chart, template, repository, and code owner before remediation is assigned.
- Review service account scope against workload need Compare each service account’s effective permissions with the workload’s actual API calls and remove permissions that exist only for deployment convenience.
- Inventory reusable templates across environments Identify charts and templates that generate multiple clusters, pods, secrets, or config maps so one misconfiguration cannot remain hidden in repeated deployments.
- Prioritise unsupported cluster versions as lifecycle debt Track unsupported Kubernetes versions separately from ordinary patch queues so lifecycle drift is visible to platform, security, and application owners.
- Assign remediation ownership at the source artifact Use code ownership and repository mapping to ensure the team that controls the chart or template is the team that fixes the exposure.
Key takeaways
- Kubernetes risk in this article is driven by governability problems as much as by technical exposure, especially where service accounts and unsupported clusters are involved.
- The article says 93% of organisations have overprivileged service accounts, which makes privilege scope a practical attack path rather than a theoretical concern.
- Source traceability from runtime objects back to Helm templates and owners is the control that changes Kubernetes remediation from guesswork to accountable action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Overprivileged service accounts are the central risk described in the article. |
| NHI-01 — Improper Offboarding | Unsupported clusters reflect lifecycle drift where old resources remain active beyond support. | |
| Recommendation — Review Kubernetes service account scope and reduce permissions that exceed the workload’s actual needs. Track unsupported Kubernetes versions as lifecycle debt and retire them before risk compounds. | ||
| MITRE ATT&CK | TA0004;TA0008 — Privilege Escalation; Lateral Movement | The article describes privilege escalation and spread through reused workload identities. |
| Recommendation — Map overprivileged service accounts to privilege escalation and lateral movement paths in cluster detection. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Kubernetes workload identities depend on tightly scoped authorizations. |
| Recommendation — Apply PR.AA-05 to verify each service account has only the entitlements its workload requires. | ||
| CIS Controls v8 | CIS-5 — Account Management | Service accounts and code owner mapping are account management and ownership issues. |
| Recommendation — Use account management controls to inventory, review, and retire Kubernetes service identities. | ||
Key terms
- Helm Chart: A Helm Chart is a reusable package of Kubernetes deployment definitions, usually built from YAML templates and configuration values. It lets teams standardise how workloads are deployed, but it also means one insecure default can be copied across many environments if governance is weak.
- Cloud-to-Dev tracing: Cloud-to-Dev tracing is the practice of linking a runtime security finding back to the code commit, template, or configuration that introduced it. It helps teams fix the origin of a problem instead of repeatedly patching the production symptom.
- Kubernetes service account: A Kubernetes service account is the identity a workload uses to call the cluster API and interact with other resources. It is a non-human identity, so its permissions, token handling, and lifecycle need governance just like any other privileged machine credential.
- Unsupported Cluster Version: An unsupported cluster version is a Kubernetes release that no longer receives standard vendor support or security updates. For governance teams, it signals lifecycle debt, because patching and compatibility options become narrower while exposure to known weaknesses persists.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org