Kubernetes security checklist for SaaS workloads
Harden Kubernetes clusters with restricted API access, least-privilege RBAC, pod security, network policies, protected secrets, and tested audit controls.
In this guide
What should a SaaS Kubernetes security checklist cover?
A Kubernetes security checklist should cover the control plane, identities, workload permissions, network paths, secrets, images, runtime settings and audit records. Kubernetes' own checklist is a baseline, not a complete security assessment; managed services and cluster versions also differ. Start by identifying the cluster and workload owners, then test each control against how the SaaS product is actually deployed and operated.
Restrict and monitor access to the Kubernetes API
Limit API-server reachability to approved operator and automation paths, require strong identity controls, and review which human and service identities can change cluster resources. Avoid using broad cluster-admin access for routine work. Protect kubelet and etcd endpoints and check the managed provider's network defaults instead of assuming they are private.
Apply narrow RBAC and enforce pod security at admission
Give each team and service account only the resource verbs and namespaces required for its job. Pay special attention to who can create or modify Pods, deployments, role bindings and admission policies because workload creation can confer access to node resources. Apply an appropriate Pod Security Standard and test enforcement before tightening a live namespace.
Use a dedicated identity for each workload
Disable automatic service-account token mounting when a workload does not call the Kubernetes API. Where it does need API access, grant a dedicated service account only the minimum verbs and resources. Use short-lived, bound tokens and provider workload identity integrations where supported rather than embedding cloud keys in manifests.
| Cluster or namespace | Identity and permissions | Network paths | Pod and secret controls | Owner, evidence and exception |
|---|---|---|---|---|
| Production API | ||||
| Customer-data worker | ||||
| Build or deployment runner |
How do you reduce Kubernetes workload attack paths?
Default to restricted network paths and add required flows
Use a network plugin that enforces Kubernetes NetworkPolicy, then define ingress and egress rules for workloads and namespaces. Start from the traffic the service needs, including DNS, identity and monitoring dependencies, and verify the plugin enforces both directions. Restrict access to cloud metadata endpoints unless a workload has a documented need.
Run containers with fewer host and kernel privileges
Avoid privileged containers, host networking, host PID or IPC access, unnecessary Linux capabilities and writable host paths. Set a non-root user and appropriate seccomp or AppArmor/SELinux controls where supported. Apply resource requests and limits based on service behavior, then monitor for throttling or memory pressure that could affect availability.
Protect secrets and verify images at deployment
Do not put credentials in ConfigMaps or source-controlled manifests. Encrypt Kubernetes Secret data at rest using the cluster's supported key controls, restrict who can read it, and avoid mounting tokens or secrets into unrelated containers. Pin production images by digest or verify trusted provenance, and scan and update images through the normal release process.
How should teams operate and review cluster security?
Separate workloads with different trust and sensitivity
Place control-plane components and high-sensitivity workloads on appropriately isolated nodes or runtimes when the platform supports it. Use namespaces to organize access and policy, but do not treat a namespace by itself as a strong tenant boundary. Document any shared nodes, cross-namespace flows and provider-managed responsibilities.
Keep audit records protected and useful for investigation
Enable the provider's Kubernetes audit facility where available, retain events that can answer who changed what and when, and limit write or delete access to the log destination. Connect cluster events with deployment, identity and cloud records using synchronized time and stable workload identifiers. Test that on-call staff can find relevant events.
Recheck controls after version, policy and architecture changes
Review deprecated APIs, admission behavior, network plugin capabilities and managed-service defaults before upgrades. Test policy changes in a non-production cluster and maintain a rollback path for workload failures. Reassess service accounts and exceptions when a product service, team or data sensitivity changes.
Kubernetes workload security FAQs
Is the official Kubernetes security checklist enough for compliance?
No. The Kubernetes project says its checklist is not exhaustive and controls may be too strict or too lax for a specific environment. Use it as a starting point, then map the service boundary, threat model, provider responsibilities and applicable requirements.
Does a namespace isolate one SaaS customer from another?
Not by itself. Namespaces organize Kubernetes resources and policy scope, but workload identity, network rules, storage, cluster permissions and application-level authorization all matter. Validate the actual tenant isolation design and do not infer it from namespace names.
Should every pod have a Kubernetes service-account token?
No. Disable automatic token mounting for workloads that do not need Kubernetes API access. For those that do, use a dedicated service account and minimum permissions, and review token lifetime and cloud identity integration for the cluster version.
Can a network policy secure Kubernetes if the CNI ignores it?
No. NetworkPolicy enforcement depends on a network plugin that implements it. Confirm the deployed CNI supports the policy features you rely on, and test both allowed and blocked traffic in a safe environment.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- Kubernetes Security ChecklistKubernetes Documentation