Draw the control plane, the nodes and workloads, and the paths between them, then walk STRIDE at each trust boundary. Kubernetes documentation groups its security mechanisms into control plane protection, workload protection, admission control and auditing, which gives you a natural checklist.
What to put in the diagram
Keep to a level the team can hold in its head.
- The API server and who or what calls it: people, CI, controllers
- The workloads, grouped by namespace or trust level
- Secrets and where they come from
- The network paths between workloads, and to the outside
- The registry that images are pulled from
- The cloud account the cluster runs in
The Kubernetes security overview says Kubernetes does not own your provider's security, and points to the AWS, Google Cloud and Azure documentation. So the cloud account is part of the model, and the shared responsibility line should be drawn on it.
Mechanisms to map threats to
| Area | Mechanisms named in Kubernetes docs | Threat question |
|---|---|---|
| Control plane | API access control, TLS in transit, encryption at rest | Who can call the API and what can they change? |
| Secrets | Kubernetes Secrets | Who can read them and where else do they appear? |
| Workload | Pod Security Standards, RuntimeClasses, NetworkPolicies | What can a compromised container reach? |
| Admission | Admission control | Which bad configurations get blocked before they run? |
| Auditing | Audit logging | Could we tell what happened afterwards? |
Three questions that surface real findings
- If one pod is compromised, what else can it reach? This tests network policy and service account permissions.
- Who can create or change workloads? This tests API access and admission rules.
- Where do images come from, and who vouches for them? This tests the registry and build path. A container image scan helps with the content, and your model decides the trust.
The Kubernetes docs also link a general security checklist and an application security checklist. Use them as the test list after you draw the model.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what an image scan reports, then decide in your model who is allowed to deploy an image with those findings.
Quick check
Does the cloud provider handle Kubernetes security for me?
Only in part. Kubernetes docs say they do not own the provider's security and point to provider guidance. Your cluster configuration and workloads remain your side of the line.
Where do I start if the cluster already exists?
Draw what exists today, then use the Kubernetes security checklists as a test list against it. Fix the highest rated gaps first.
A note on tooling
Safeguard covers container image scanning, SBOM and dependency scanning and policy gates, which check what goes into the cluster. Try the free scan.
Sources
Last reviewed: 19 October 2026.
