Which Kubernetes security tools do you need, layer by layer?

You need tools for six layers of a Kubernetes cluster: control of the API, workload isolation, network policy, secrets, admission control and audit logging. Kubernetes ships basic controls for each. Add external tools only where a layer has a gap you can name, such as image scanning, runtime detection or policy at scale.

What does Kubernetes give you out of the box?

The security section of the Kubernetes documentation organizes the controls into groups, and the groups are a good checklist.

Control plane access. Restrict who can reach the API and what they can do. Role based access control, service accounts and TLS for traffic to and within the control plane belong here. Encryption at rest for control plane data is optional and worth enabling.

Workload isolation. Pod Security Standards, enforced by Pod Security Admission, set baseline limits on what pods may do, such as running privileged. RuntimeClasses allow stronger isolation for sensitive workloads.

Network. NetworkPolicies control traffic between pods and to or from outside the cluster. The docs describe them as network packet filtering for pods.

Secrets. The Secret API gives basic protection for confidential values. The docs add good practice pages for handling them.

Admission control. Admission controllers intercept API requests and validate or modify them. ValidatingAdmissionPolicy lets you restrict changes through Kubernetes native rules.

Audit. Audit logs give a chronological record of actions by users, applications and the control plane.

Where do external tools help?

The documentation says plainly that ecosystem tools can add preventive or detective controls on pods, containers and images. Typical gaps:

• Image and dependency scanning. Before an image is deployed, scan it for known vulnerable packages and secrets. This catches problems at build time, which is cheaper than at runtime. Safeguard's dependency scanning and policy gates work on this layer, upstream of the cluster.
• Configuration checks. Tools that lint manifests and cluster settings against a benchmark catch risky settings early.
• Policy engines. For many clusters, a policy engine applies the same admission rules everywhere.
• Runtime detection. Watching what containers actually do, such as spawning shells or reading sensitive files, detects what static checks miss.
• Secrets management. An external vault can issue short lived credentials instead of storing long lived ones as Secrets.
• Network visibility. Flow logs show what talks to what, which helps you write network policies that are tight but not broken.

Constructed example: the namespace that talked to everything

A team deploys a new internal service into a shared namespace. No network policy exists, so every pod in the cluster can reach it, including a public facing web pod. The web pod is later compromised through a vulnerable library, and the attacker calls the internal service directly. A default deny policy with explicit allows would have blocked the path, and an admission rule requiring a policy per namespace would have prevented the gap. The scenario is invented, but the missing network policy is a common finding.

How do you sequence the work?

Start with the cheap, high value basics: tighten RBAC, turn on Pod Security Admission in enforcing mode for new namespaces, add default deny network policies, enable audit logging. Then add image scanning in the pipeline. Add runtime detection and a policy engine when the cluster count or sensitivity justifies them.

The Kubernetes documentation also has a security checklist and a page on API server bypass risks, which are worth reading before you decide anything.

How to check or apply this

1. List your clusters, their owners and what data runs on them.
2. Review RBAC for wildcard roles and unused service accounts.
3. Enforce Pod Security Standards and ban privileged pods by default.
4. Apply default deny network policies and add explicit allow rules.
5. Move secrets out of manifests and consider short lived credentials.
6. Scan images and dependencies in CI, and block deployment on findings you decide matter.
7. Enable audit logs and send them somewhere reviewed.

Quick check

Sources

• Kubernetes documentation, Security

Last reviewed: 18 October 2026.