Start by mapping the system design, communication paths, data flows, and trust boundaries for each service or deployment. Then identify likely threats against those components and decide on countermeasures, investigation steps, or mitigations. In Kubernetes, the model should reflect namespaces, nodes, clusters, and access governance so the analysis matches the real deployment rather than a generic architecture.
Map Kubernetes by workload, not by cluster alone
A useful Kubernetes threat model starts with the deployed service as the unit of analysis, then expands to the namespace, node, cluster, and any external dependency that can change the service’s security posture. That means tracing east-west traffic, ingress and egress paths, and which workloads can talk to which APIs, rather than assuming the cluster boundary is the only trust boundary.
For security teams, the practical value is that Kubernetes risk is often created by the interaction between service design and platform policy. A service may be safe in isolation but become exposed when it shares a namespace, inherits a permissive network policy, or runs with a node-level capability that broadens blast radius.
One useful reference point is NHI Mgmt Group’s Ultimate Guide to NHIs, which is especially helpful when the service depends on workload credentials, API keys, tokens, or other access material that should be modelled as part of the service path, not as an afterthought.
When the model is anchored in the real deployment, it becomes easier to separate local compromise from cluster-wide compromise, and to see where policy should constrain service-to-service communication, secret exposure, or privileged node access.
Threats and controls should follow the Kubernetes control plane relationships
Threat modelling in Kubernetes is most effective when each major relationship is tested for abuse: pod-to-pod communication, pod-to-API-server access, service-account usage, secret consumption, image pull permissions, and any controller or admission path that can alter runtime behaviour. Those relationships define how an attacker would move, escalate, or persist if one workload is compromised.
Security teams should treat overbroad RBAC, default service accounts, and unrestricted namespace permissions as first-class threat inputs. The same is true for exposed secrets, because a single leaked token or credential can convert a normal application compromise into unauthorized cluster access or lateral movement into adjacent workloads.
The strongest external control reference in this area is the OWASP Non-Human Identity Top 10, which aligns well with Kubernetes services that rely on service accounts, tokens, or other machine-held access material. For broader control mapping, CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support access governance, auditability, and configuration control, which are central to Kubernetes threat models.
For container-specific platform risk, the NIST SP 800-190 Container Security guide is directly relevant because it helps teams think through image, registry, orchestrator, and runtime exposure as a connected attack surface.
What good looks like in a Kubernetes threat model
Good Kubernetes threat models are specific enough to drive decisions. They identify which services are internet-facing, which workloads handle sensitive data, which identities can deploy or mutate resources, and which assumptions would fail if an attacker gained pod-level execution. They also make it obvious where security policy must be enforced in the platform rather than inside the application.
What to verify: Every deployed service should have an explicit data flow map, a named trust boundary, a documented service account or equivalent access path, and a clear answer to what happens if that workload is compromised. If those elements cannot be produced quickly, the threat model is probably still too abstract to be operationally useful.
What to prioritise: Start with services that have external reach, sensitive data access, or permissions that cross namespace or cluster boundaries. Those are the places where a small misconfiguration can create disproportionate exposure.
Practitioner takeaway: A Kubernetes threat model is only valuable when it explains how a real service can be reached, what it can touch, and how far an attacker could travel from that foothold before controls interrupt the path.
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 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Kubernetes services rely on workload credentials and tokens that must be governed as access material. |
| NHI-03 — Least Privilege and Access Scoping | Kubernetes RBAC and service permissions directly determine workload blast radius. | |
| NHI-05 — Lifecycle and Revocation | Deployed services need revocation and offboarding logic when identities, tokens, or deployments change. | |
| Recommendation — Inventory and rotate service credentials to reduce secret sprawl and token abuse. Scope workload permissions to the minimum verbs, resources, and namespaces required. Revoke unused workload access paths promptly when services are removed or redeployed. | ||
| CIS Controls v8 | 6 — Access Control Management | Kubernetes threat modelling depends on controlling accounts, roles, and access paths. |
| 8 — Audit Log Management | Threat modelling should account for observability of cluster activity and access changes. | |
| 4 — Secure Configuration of Enterprise Assets and Software | Namespace, network, and runtime settings strongly shape Kubernetes exposure. | |
| Recommendation — Restrict cluster and workload access to approved roles and business need. Log cluster and workload actions so suspicious access paths can be investigated. Harden Kubernetes configurations to reduce misconfiguration-driven attack paths. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Kubernetes access governance depends on authentication and authorization across users and workloads. |
| DE.CM — Security Continuous Monitoring | Threat models should feed detection coverage for cluster activity and service abuse. | |
| Recommendation — Enforce authentication and authorization on every path that can alter or reach workloads. Monitor runtime and control-plane activity for abnormal access and lateral movement. | ||
| NIST SP 800-53 Rev 5 | AC — Access Control | Kubernetes permissions and trust boundaries are fundamentally access-control problems. |
| AU — Audit and Accountability | Threat modelling should define how access and privilege changes are traced. | |
| Recommendation — Apply least-privilege access controls to namespace, node, and API operations. Capture audit trails for workload, identity, and cluster-admin actions. | ||
Related resources from NHI Mgmt Group
- How should security teams design access controls so network permissions and application permissions stay aligned?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams threat model AI agents in Kubernetes?
- How should security teams prevent AI search services from bypassing masking and access controls in Snowflake?
