TL;DR: Kubernetes security now spans scanning, runtime detection, policy enforcement, and access control because perimeter tools cannot answer who is authorised inside a cluster, according to Pomerium. Existing IAM and network models break when workloads are ephemeral and access must be verified per request, not assumed from location.
At a glance
What this is: This is a Pomerium guide to Kubernetes security tooling that argues IAM and perimeter controls still fail when clusters are dynamic, ephemeral, and authorization must be decided per request.
Why it matters: It matters because Kubernetes security now depends on how IAM, policy, runtime detection, and access control work together across build, deploy, and live access decisions.
By the numbers:
- 67% of companies have delayed deployments due to Kubernetes security issues.
- 87% of container images were found to include a high or critical vulnerability.
Context
Kubernetes security is the problem of governing access, configuration, and runtime behavior in environments that change too quickly for perimeter assumptions to hold. In a cluster, pods appear and disappear, services span namespaces, and access decisions need to follow identity and context rather than location.
Pomerium’s article frames the central gap clearly: traditional IAM and network segmentation can still be blind to who is making a request inside the cluster. That leaves practitioners with a governance problem as much as a tooling problem, especially when build, deploy, and live access all need different controls.
The article’s core message is that no single Kubernetes control plane is enough. Security teams have to treat configuration scanning, vulnerability scanning, runtime detection, policy enforcement, and access control as complementary layers, not substitutes.
Key questions
Q: What should teams do first when Kubernetes security controls are fragmented across tools?
A: Start by mapping each tool to a specific stage of the container lifecycle. Use scanning before deployment, admission controls at creation time, runtime detection for live workloads, and access controls for request-time decisions so responsibilities do not overlap or leave gaps.
Q: Why do internal network controls fail to secure Kubernetes by themselves?
A: Because internal reachability does not prove identity or ongoing authorization. A pod or user inside the cluster can still be unauthorized, overprivileged, or compromised, so network controls need to be paired with identity-aware access decisions and audit logging.
Q: What breaks when Kubernetes access is controlled only by network location?
A: Network-only control breaks because it does not verify who is acting, what role they hold, or whether the access is still appropriate. In Kubernetes, that can allow a trusted network path to expose cluster-admin functions, secrets, and workloads. Identity-aware policy is needed to replace location as the trust signal.
Q: How should security teams compare Kubernetes network policy and Zero Trust access control?
A: Network policy restricts which workloads can talk to each other, while Zero Trust access control decides who may reach services and under what conditions. They solve different problems, so one cannot replace the other in a mature Kubernetes programme.
Technical breakdown
Why perimeter controls fail in Kubernetes
Kubernetes breaks the assumptions behind static network security. Perimeter tools can filter traffic, but they do not understand whether a request comes from an approved identity, whether the workload is still authorised, or whether the request is happening inside a namespace that should be isolated. That is why cluster security shifts from location-based trust to identity-aware enforcement. In practical terms, the failure is not only visibility. It is the mismatch between a dynamic orchestration model and security controls built for fixed infrastructure.
Practical implication: Use identity-aware authorization at the cluster boundary instead of relying on network location as the trust signal.
How scanning, runtime security, and policy enforcement differ
The article separates three controls that are often conflated. Configuration scanning checks manifests, Helm charts, and IaC before deployment. Runtime security watches live workloads for suspicious behavior such as shell spawning or privilege escalation. Policy enforcement blocks non-compliant resources at admission before creation. Each layer catches a different class of failure, so swapping one for another creates blind spots. The operational lesson is that Kubernetes security is a lifecycle problem, not a single control problem.
Practical implication: Map controls to build, admission, and runtime stages so each failure mode has a distinct detection or prevention point.
Identity-aware access control for internal services
Access control in Kubernetes is not the same as network policy. Network policy limits pod-to-pod communication, while identity-aware access control decides who can reach services in the first place and under what context. That distinction matters because Zero Trust requires per-request authorization, auditability, and continuous evaluation rather than implied trust from an internal network. In the article, Pomerium is positioned in that access layer, where human, service, and agent access all need the same governance logic.
Practical implication: Separate service reachability controls from identity-based access decisions and review both as part of your Zero Trust design.
Threat narrative
Attacker objective: The attacker aims to turn cluster trust assumptions into lateral movement and unauthorized service access inside Kubernetes.
- Entry occurs when attackers or unauthorized requests reach a cluster through assumptions that treat internal traffic as trusted.
- Credential or authorisation abuse follows when access is inferred from location, broad network reach, or stale trust rather than per-request identity checks.
- Impact comes when a compromised workload or unauthorized user moves across services because segmentation and access controls were not tied tightly enough to identity.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
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
Perimeter trust is the wrong abstraction for Kubernetes access. The article reinforces a broader identity-security reality: clusters are too dynamic for location-based trust to remain the primary control. When pods, services, and requests are ephemeral, authorization has to follow the request, not the network path. Practitioners should treat internal network presence as an insufficient trust signal.
Lifecycle-stage control separation is now mandatory. Configuration scanning, vulnerability scanning, runtime detection, policy enforcement, and access control solve different problems, and the article correctly places them on different parts of the delivery chain. That matters because teams still collapse them into a single “Kubernetes security” programme and then miss the failure mode they actually need to govern. The practical conclusion is that each stage needs its own control owner and evidence model.
Identity-aware access is becoming the decisive Kubernetes control layer. The article’s strongest implication is that network policy alone no longer answers the governance question that matters most: who can reach what, under what conditions, and with what audit trail. That shifts Kubernetes security from transport-level restriction to identity-led decisioning. The practitioner takeaway is to align access policy, auditability, and workload context in one governance model.
Zero Trust for Kubernetes is really per-request authorization at scale. Zero Trust only becomes meaningful in Kubernetes when it is applied continuously to services, workloads, and humans rather than treated as a perimeter label. That makes access control a live policy problem, not a one-time deployment choice. Teams that keep authorization static will keep inheriting blind spots from the old network model.
Credential and policy drift are the hidden costs of ephemeral infrastructure. Ephemeral clusters do not just increase operational churn; they make stale permissions and outdated assumptions easier to overlook. The article points to a governance pattern where security evidence must be generated as close to runtime as possible, because build-time checks alone cannot prove ongoing trust. Practitioners should expect the control burden to move closer to execution.
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
Identity-aware Kubernetes governance now matters more than perimeter hardening. The article shows why cluster security has moved past traffic filtering and toward request-level authorization. Practitioners should expect more pressure to prove who can access internal services, not just which pods can communicate.
Control ownership should follow the attack surface, not the tool category. Teams that split scanning, policy, runtime, and access control across different owners tend to discover gaps only after deployment. The better pattern is to align each control with the point in the lifecycle where it can still prevent or prove trust.
Per-request authorization becomes the new baseline for Kubernetes access. The article’s strongest signal is that ephemeral infrastructure makes static trust models brittle. Security programmes that cannot produce an access decision per request will struggle to defend zero trust claims in production.
For practitioners
- Define controls by delivery stage Assign configuration scanning to pre-deployment checks, policy enforcement to admission, runtime detection to live workloads, and access control to request-time authorization.
- Separate network policy from access policy Use network policy for pod-to-pod segmentation and identity-aware access controls for who can reach services, APIs, and internal applications.
- Review Kubernetes access through Zero Trust assumptions Require per-request authorization, device or context checks where appropriate, and audit trails for all human, service, and agent access.
- Fail builds on misconfiguration and known vulnerabilities Push IaC scanning and image vulnerability checks into CI/CD so risky manifests and containers are blocked before cluster admission.
Key takeaways
- Kubernetes security fails when teams treat dynamic clusters like static networks, because internal location does not equal authorization.
- The article separates prevention, detection, and access control across the delivery lifecycle, which is the right way to avoid false overlap between tools.
- Practitioners should move toward identity-aware, per-request access decisions while keeping scanning and policy enforcement in their proper lifecycle stages.
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, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on request-time trust and identity-based access inside dynamic clusters. |
| NHI-05 — Overprivileged NHI | Kubernetes workloads and service identities need scoped access rather than broad internal reach. | |
| Recommendation — Apply NHI-04 to replace location-based trust with request-time authentication for cluster access. Review workload and service permissions for overprivilege and narrow them to required cluster actions. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Services, workloads, and APIs authenticating to each other are central to the article's access model. |
| AC-6 — Least Privilege | The article repeatedly highlights limiting access to reduce blast radius in Kubernetes. | |
| Recommendation — Use IA-9 to authenticate non-human services before granting cluster or service access. Enforce AC-6 so each workload and user receives only the permissions needed for its current task. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Per-request authorization and entitlement control are the core governance themes in the article. |
| Recommendation — Apply PR.AA-05 to continuously validate entitlements before allowing Kubernetes service access. | ||
| NIST Zero Trust (SP 800-207) | Policy enforcement point — Policy enforcement point | The article argues for request-time decisions at the point where access is enforced. |
| Recommendation — Place policy enforcement at the request boundary so Kubernetes access is evaluated before traffic is admitted. | ||
| MITRE ATT&CK | TA0008;TA0004 — Lateral Movement; Privilege Escalation | The article notes that compromised workloads can spread when internal trust is too broad. |
| Recommendation — Map Kubernetes trust gaps to lateral movement and privilege escalation paths in your detections. | ||
Key terms
- Kubernetes Access Management: Kubernetes access management is the control of who and what can interact with clusters, namespaces, workloads, and control plane functions. It combines platform identity, role design, and workload authorization. Because Kubernetes often sits inside larger cloud estates, it adds another layer of access complexity that must be governed separately and consistently.
- Admission Controller: An admission controller is a Kubernetes control that validates or changes workload requests before the cluster admits them. It acts as a deployment-time policy layer, which makes it useful for blocking unsafe images, rejecting risky configuration, and enforcing runtime standards that build-time scans may miss.
- 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.
- Per-Request Authorization: Per-request authorization means every action is checked individually instead of trusting a session once and assuming all later activity is safe. This matters for agents because the request that causes damage may be generated after the initial interaction has already been approved. It is a stronger fit for dynamic, tool-using identities.
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 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org