TL;DR: Gartner’s 2029 forecast says more than 95% of global organisations will run containerised applications in production, while 35% of enterprise applications will run in containers, underscoring that Kubernetes security is now a mainstream governance problem, according to Aqua Security. Security models built for static infrastructure no longer fit ephemeral, rapidly redeployed workloads.
At a glance
What this is: Aqua Security argues that Kubernetes security has crossed into mainstream adoption, and the old model of treating containers like stable infrastructure no longer fits ephemeral, orchestrated workloads.
Why it matters: IAM, PAM, and cloud security teams need to treat Kubernetes as a governance problem as much as a platform problem, because authentication, workload identity, and configuration discipline now directly shape operational risk.
By the numbers:
- By 2029, more than 95% of global organisations will be running containerized applications in production, according to Gartner research cited by Aqua Security.
- By 2029, 35% of all enterprise applications will run in containers, according to Gartner research cited by Aqua Security.
Context
Kubernetes security is the discipline of controlling access, workload behaviour, configuration, and data paths in an environment where applications are repeatedly built, scheduled, replaced, and scaled. The governance challenge is that the control plane and the workloads it runs are both dynamic, so assumptions that work for static infrastructure break down quickly.
Aqua Security’s article frames Kubernetes adoption as mainstream rather than emerging, which changes the security conversation from experimentation to operating model. Once containerised applications become the default delivery path, security teams have to align control design with ephemeral workloads, shared responsibility, and continuous remediation instead of relying on legacy network-bound assumptions.
Key questions
Q: How should security teams govern Kubernetes workloads that change constantly?
A: Treat Kubernetes governance as a continuous control problem. Tie image validation, deployment policy, namespace access, and runtime detection into one operating loop so short-lived workloads do not outrun review cycles. The goal is to prevent unsafe states from reaching production and to make any detected issue traceable back to the manifest, pipeline, or cluster permission that created it.
Q: Why do static security controls struggle in Kubernetes?
A: Static controls struggle because Kubernetes changes too quickly for predefined rules alone to stay accurate. Containers are ephemeral, workloads shift frequently, and the attack surface changes as services scale or redeploy. Without runtime context, teams miss live behavior, misjudge risk, and create alerts that are either too broad or too narrow to support fast, reliable response.
Q: What are the signs that Kubernetes security controls are not keeping pace with cloud-native risk?
A: Warning signs include frequent misconfigurations, insecure APIs, overly permissive settings, and limited runtime visibility inside containers. If security checks are not built into CI/CD, problems tend to reach production before they are caught. In practice, weak Kubernetes security shows up when teams cannot see container activity in real time or prevent avoidable configuration drift.
Q: What should teams do when Kubernetes security is split across developers, SREs, and security?
A: Teams should define shared ownership for images, manifests, cluster permissions, and runtime response so no group can hand off risk without context. Kubernetes governance breaks down when each team sees only part of the lifecycle and the same flaw keeps re-entering the platform.
Technical breakdown
Why ephemeral Kubernetes workloads break static security models
Containers and pods are short-lived by design, and Kubernetes is built to reschedule them automatically. That means location-based controls, long sampling intervals, and asset assumptions tied to a stable host model are unreliable. Security baselines must account for workload churn, not just where an application runs at a point in time. In practice, the meaningful control points move toward image integrity, policy at deployment, runtime observability, and identity-bound access rather than perimeter assumptions.
Practical implication: map controls to workload identity, policy enforcement, and runtime monitoring instead of relying on fixed-network or host-based assumptions.
Why Kubernetes configuration becomes an identity and access problem
Kubernetes security is not only about pods and images. The article points to authentication, resource limits, cluster state, networking, and storage as areas where misconfiguration creates risk. In operational terms, the control plane governs who can do what, while YAML and policy objects determine what the platform will allow. That makes cluster governance closely related to IAM, least privilege, and entitlement review, especially when teams automate deployments at speed.
Practical implication: review cluster authentication, service account scope, and administrative entitlements as part of Kubernetes security governance.
Why DevSecOps must connect build-time and runtime controls
The article is clear that runtime protection alone is not enough if the environment keeps reintroducing the same flaws through images, supply chain inputs, or Kubernetes manifests. In container platforms, preventive hygiene reduces noise and makes runtime signals useful. That creates a closed loop between build-time checks, deployment policy, and live detection. Security teams that separate these layers tend to chase symptoms instead of removing the root causes of recurring exposure.
Practical implication: tie container image hygiene, manifest review, and runtime detection into one remediation loop rather than treating them as separate teams.
NHI Mgmt Group analysis
Kubernetes security has become a governance discipline, not a niche platform concern. Once containerized applications are mainstream, the question is no longer whether teams will adopt Kubernetes but whether their control model can survive its speed and ephemerality. Security programmes built around stable assets, fixed IPs, and slow change windows lose precision as soon as orchestration becomes the operating norm. The implication is that Kubernetes needs identity-aware, policy-driven governance rather than infrastructure assumptions.
The core failure mode is permanence thinking. The article’s strongest point is that containers, pods, and clusters are temporary by design, while many security models still assume long-lived assets and review cycles. That creates a runtime governance gap: by the time a control observes the workload, the workload may already have moved, been replaced, or scaled out. Practitioners should treat temporal instability as a first-class security constraint, not an operational inconvenience.
Shared responsibility only works when engineering and security work from the same control boundaries. Aqua Security’s framing shows that remediation cannot stop at alerting or vulnerability discovery. If developers, SREs, and security teams do not share context about images, manifests, and cluster permissions, the same misconfiguration will recur across releases. The field needs repeatable governance around Kubernetes build, deploy, and runtime stages, not isolated point controls.
Ephemeral workload governance: Kubernetes forces security teams to govern identities, policies, and runtime states that may exist for seconds rather than days. That changes how access, auditability, and remediation are defined across cloud native environments. The practitioner conclusion is straightforward: control design has to be lifecycle-aware and workload-native.
Shift-left and runtime security are now inseparable in container platforms. In Kubernetes, the only sustainable model is one that reduces attack surface before deployment and validates behaviour after deployment. If either side is missing, the other becomes overwhelmed with noise or blind spots. Security leaders should align prevention, detection, and remediation around the same workload lifecycle.
From our research library:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
What this signals
Ephemeral workload governance: Kubernetes forces security teams to govern identities, policies, and runtime states that may exist for seconds rather than days. That changes how access, auditability, and remediation are defined across cloud native environments. The practitioner conclusion is straightforward: control design has to be lifecycle-aware and workload-native.
The practical shift is from infrastructure-centric security to platform governance that can follow deployment churn. Teams that keep using static asset assumptions will continue to under-collect evidence, over-rely on perimeter controls, and miss the configuration drift that makes container platforms fragile.
For practitioners
- Rebuild controls around workload ephemerality Replace host-anchored assumptions with controls that follow the container lifecycle, including image integrity checks, deployment policy, and runtime telemetry.
- Review Kubernetes authentication and cluster permissions Examine service account scope, admin entitlements, and platform authentication paths as part of the security baseline for every cluster.
- Tie manifest hygiene to runtime detection Treat Kubernetes YAML review, image scanning, and live anomaly detection as one control loop so root causes are removed, not just observed.
- Build shared remediation context for DevSecOps teams Give developers, SREs, and security teams the same view of what broke, where it lives, and how it should be fixed before the next redeploy.
Key takeaways
- Kubernetes security now has to be treated as a mainstream governance issue because containerized applications are moving into the default operating model.
- The real weakness is not containers themselves but control designs that assume permanence in a system built for rapid replacement and orchestration.
- Practitioners need to connect build-time hygiene, deployment policy, and runtime monitoring if they want security to keep pace with cloud native delivery.
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 SP 800-53 Rev 5 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 | Kubernetes service accounts and workload identities can accumulate excess privilege in clusters. |
| NHI-06 — Insecure Cloud Deployment Configurations | The article centers on misconfiguration in Kubernetes cluster setup and deployment state. | |
| Recommendation — Audit Kubernetes workload identities for overprivilege and trim service account scope to least required access. Review cluster and manifest configuration for insecure defaults that expand exposure during deployment. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication of Non-Organizational Users | Kubernetes and workload authentication are central to cluster governance and access control. |
| Recommendation — Apply IA-9 principles to machine and workload authentication paths inside Kubernetes platforms. | ||
| CIS Controls v8 | CIS-5 — Account Management | Cluster access, service accounts, and shared responsibility all hinge on account governance. |
| Recommendation — Use account management controls to inventory and review Kubernetes service and admin accounts. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Compromised cluster credentials and overbroad permissions are common enablers of Kubernetes compromise. |
| Recommendation — Map cluster credential exposure and pivot paths to credential access and lateral movement detections. | ||
Key terms
- Kubernetes Security: The discipline of protecting clusters, workloads, and the automation that connects them. It combines identity, configuration, network, and runtime controls because a weakness in any one layer can expose the whole deployment path.
- Workload Ephemerality: Workload ephemerality is the short-lived nature of containers, pods, and related runtime objects. Security programmes have to account for assets that may be created, moved, and destroyed faster than traditional inventory, audit, or sampling processes can track them.
- Cluster authentication state: The cached identity information a clustered application uses to decide whether a request is already authenticated. In Tomcat-style architectures, this state may be replicated between nodes, which makes it a high-value target because manipulating it can bypass the normal login flow and inherit the application’s access decisions.
- Runtime Security: Runtime security is the practice of detecting and constraining malicious behavior while software is executing. It focuses on live workload activity, not just code quality or pre-deployment checks, so teams can contain abuse after a system is already running.
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 or cloud security programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org