Most Kubernetes compromises start with a cluster that went live on default settings: a reachable API server, an anonymous kubelet, wide RBAC grants and pods running as root with a service account token they never needed. This template turns the upstream Kubernetes Security Checklist and the NSA and CISA Kubernetes Hardening Guidance into a production sign-off standard with a verification method for every item. It covers the control plane, nodes, RBAC and service accounts, workloads, network, secrets, images, admission control and audit logging, and notes where managed services such as Amazon EKS, Azure AKS and Google GKE change who owns a control. It is written for platform engineers, security architects and reviewers who must approve a cluster before production traffic reaches it. Replace the values in square brackets and approve it through your normal policy process.
This is an independent guide from NHI Mgmt Group, based on the Kubernetes project's public documentation as of November 2026. It is not sponsored or reviewed by the Kubernetes project. Product features change, so confirm settings against the Kubernetes project's current documentation.
How to use this template
- Replace text in square brackets, such as [Organisation], [Platform engineering] and [90 days], with your own roles and values.
- "Must" items block production sign-off; "should" items need an approved exception under section 8 if not met.
- Copy the tables in section 6 into your tracker and add a Status column (Met, Not met, Exception, Provider) per cluster. "Provider" means the cloud provider operates that control under the shared responsibility model; record the provider documentation you relied on.
- A check is met only when the "Verify" test passes against the live cluster, not when a manifest has been written.
- For the risks behind these checks, read the Top 10 Kubernetes Security Risks; for the full architecture view, the Kubernetes Security Guide.
1. Purpose
This standard sets the minimum security configuration a Kubernetes cluster at [Organisation] must meet before it runs production workloads, and the evidence needed to prove it. It is based on the Kubernetes project's Security Checklist, the Pod Security Standards, the NSA and CISA Kubernetes Hardening Guidance (version 1.2, August 2022) and the CIS Kubernetes Benchmark for the distribution in use. The upstream checklist itself warns that a checklist is not sufficient on its own and that some items may be too strict or too lax for a given environment, so section 8 provides the exception route.
2. Scope
- Every Kubernetes cluster that runs [Organisation] production workloads or holds production data, whether self-managed (kubeadm, Rancher, OpenShift) or managed (EKS, AKS, GKE and similar).
- Non-production clusters that hold production data, production credentials or a network path to production.
- The CI/CD pipelines, registries and GitOps controllers that can change what runs in those clusters.
Workload application security (code, dependencies, business logic) is covered by [Application Security Standard].
3. Roles and responsibilities
- [Head of Platform Engineering]: owns this standard, maintains the baseline as code and signs off each cluster.
- [Security architecture]: reviews deviations, approves exceptions above [risk threshold] and runs the CIS Benchmark scan.
- [Security operations]: receives audit logs and runtime alerts and runs the Kubernetes Cluster Compromise Playbook.
- [IAM team]: owns human access via the identity provider, break-glass credentials and periodic access reviews.
- Application teams: deploy only through the approved pipeline and meet the namespace's Pod Security level.
4. Definitions
- Pod Security Standards (PSS): the three upstream profiles: Privileged (unrestricted), Baseline (blocks known privilege escalations) and Restricted (current pod hardening practice).
- Pod Security Admission (PSA): the built-in admission controller that applies a PSS level per namespace through the labels
pod-security.kubernetes.io/enforce,auditandwarn. - Bound service account token: a short-lived, audience-bound token projected into a pod, replacing the old non-expiring Secret-based token.
- Break-glass: emergency cluster-admin access, held offline, logged and reviewed after each use.
5. Baseline selection
[Organisation] must adopt one published benchmark per distribution and record its version. As checked on 8 November 2026, CIS publishes these Kubernetes benchmarks:
| Distribution | CIS Benchmark (version) | Who owns control plane checks |
|---|---|---|
| Upstream / self-managed | CIS Kubernetes Benchmark 2.1.0 | [Organisation]: API server, etcd, controller manager, scheduler, kubelet |
| Amazon EKS | CIS Amazon EKS Benchmark 2.1.0 (EKS Auto Mode 1.1.0) | Provider for control plane; [Organisation] for nodes, RBAC, workloads, network |
| Azure AKS | CIS AKS Benchmark 2.1.0 (AKS Automatic 1.0.0) | Provider for control plane; [Organisation] for nodes, RBAC, workloads, network |
| Google GKE | CIS GKE Benchmark 2.0.0 (GKE Autopilot 2.0.0) | Provider for control plane; Autopilot also shifts node configuration to the provider |
| Red Hat OpenShift | CIS OpenShift Container Platform Benchmark 2.0.0 | Depends on self-managed or managed offering |
Run the cluster on a Kubernetes minor version that is still supported. The project maintains the three most recent minor releases and supports each patch series for roughly 14 months; an unsupported version receives no security fixes. Managed services publish their own support calendars, which apply instead. See the Azure Kubernetes Service Security Hardening Guide for AKS specifics.
6. Hardening checklist
6.1 Control plane and etcd
| # | Requirement | Level | Verify |
|---|---|---|---|
| 6.1.1 | The API server is not reachable from the internet; access is via private endpoint, allow-listed CIDRs or a bastion. | Must | External scan of the endpoint; managed service endpoint access setting shows private or restricted. |
| 6.1.2 | etcd is not exposed, uses mutual TLS, and has a certificate authority unique to etcd. | Must (self-managed) | etcd flags show client cert auth and peer TLS; CA differs from cluster CA. |
| 6.1.3 | Secrets are encrypted at rest with --encryption-provider-config, first provider not identity; KMS v2 preferred over local keys. | Must | EncryptionConfiguration reviewed; a test Secret read directly from etcd is not plaintext. Managed: envelope encryption with provider KMS enabled. |
| 6.1.4 | kube-controller-manager runs with --use-service-account-credentials. | Must (self-managed) | Static pod manifest or process flags. |
| 6.1.5 | The cluster root CA is offline or in a managed CA with effective access controls; intermediate and leaf certificates expire no more than 3 years ahead. | Must | CA custody record; certificate expiry report. |
| 6.1.6 | Recommended admission plugins are enabled: NodeRestriction, PodSecurity, and DenyServiceExternalIPs unless externalIPs are needed. | Must | --enable-admission-plugins value; provider documentation for managed clusters. |
6.2 Nodes and kubelet
| # | Requirement | Level | Verify |
|---|---|---|---|
| 6.2.1 | Kubelet anonymous authentication is disabled (--anonymous-auth=false or authentication.anonymous.enabled: false). | Must | KubeletConfiguration on a sample node; unauthenticated request to the kubelet API returns 401. |
| 6.2.2 | Kubelet authorisation mode is Webhook, not the default AlwaysAllow. | Must | KubeletConfiguration; CIS Benchmark scan result. |
| 6.2.3 | The kubelet API is not reachable from outside the cluster network. | Must | Security group or firewall rules; external scan. |
| 6.2.4 | Nodes run a minimal, patched OS image with automated node replacement or patching within [14 days] of a critical fix. | Must | Node image age report. |
| 6.2.5 | Sensitive workloads run on dedicated node pools or a sandboxed RuntimeClass, enforced with taints, PodNodeSelector or PodTolerationRestriction. | Should | Scheduling policy review; pod placement report. |
6.3 Authentication, RBAC and service accounts
| # | Requirement | Level | Verify |
|---|---|---|---|
| 6.3.1 | Humans authenticate through the corporate identity provider (OIDC or the managed service's IAM integration) with MFA; no shared or static user credentials. | Must | Authentication config; kubeconfig audit. |
| 6.3.2 | The system:masters group is not used for users or components after bootstrap; it is break-glass only. | Must | Certificate and binding review; audit log search for system:masters use. |
| 6.3.3 | Rights are granted with namespaced RoleBindings where possible, no wildcard verbs or resources, and no bindings to system:unauthenticated beyond defaults. | Must | RBAC export reviewed with kubectl auth can-i --list per subject or an RBAC analysis tool. |
| 6.3.4 | High-risk permissions are restricted to named platform roles: escalate, bind, impersonate, read on Secrets, create on pods or workload controllers, and get on nodes/proxy (which is not read-only). | Must | Query of all bindings granting these verbs. |
| 6.3.5 | automountServiceAccountToken: false is set on the default service account and on pods that do not call the API. | Must | Admission policy report; pods with mounted tokens listed and justified. |
| 6.3.6 | Only bound, projected service account tokens are used; no long-lived Secret-based tokens exist. | Must | List Secrets of type kubernetes.io/service-account-token. |
| 6.3.7 | Access reviews of cluster roles and bindings happen at least every [6 months] (upstream ceiling: 24 months). | Must | Signed review record. |
Service account design is covered in the Kubernetes RBAC Guide and the Kubernetes Service Account Token Guide.
6.4 Workloads and Pod Security
| # | Requirement | Level | Verify |
|---|---|---|---|
| 6.4.1 | Every namespace carries a pod-security.kubernetes.io/enforce label: restricted for application namespaces, baseline only by exception, privileged only for named system namespaces. | Must | List namespaces without an enforce label (target: none). |
| 6.4.2 | Containers run as non-root (runAsNonRoot: true), with allowPrivilegeEscalation: false and capabilities.drop: ["ALL"]. | Must | Restricted enforcement passes; admission audit shows no violations. |
| 6.4.3 | No privileged, hostNetwork, hostPID, hostIPC or hostPath outside approved system workloads. | Must | Policy report across all namespaces. |
| 6.4.4 | Seccomp profile RuntimeDefault (or a Localhost profile) applies to every Linux workload; AppArmor or SELinux enabled where nodes support it. | Must | Pod specs or kubelet default seccomp setting. |
| 6.4.5 | Memory limits are set and do not exceed requests; ResourceQuota and LimitRange exist per namespace. | Should | Quota and LimitRange objects present. |
6.5 Network
| # | Requirement | Level | Verify |
|---|---|---|---|
| 6.5.1 | The CNI plugin enforces NetworkPolicy. | Must | Test: a deny policy actually blocks traffic between two test pods. |
| 6.5.2 | Each namespace has a default-deny ingress and egress policy, with explicit allow rules. | Must | Namespaces without a default-deny policy (target: none). |
| 6.5.3 | Pod access to the cloud metadata endpoint 169.254.169.254 is blocked unless required, and workload cloud access uses workload identity rather than node credentials. | Must | Test request from a pod fails; workload identity configured. |
| 6.5.4 | Creation of LoadBalancer Services and use of externalIPs is restricted. | Must | Admission policy; list of public Services approved. |
| 6.5.5 | Traffic between workloads carrying sensitive data is encrypted (CNI encryption or service mesh mTLS). | Should | Mesh or CNI configuration. |
6.6 Secrets, images and supply chain
| # | Requirement | Level | Verify |
|---|---|---|---|
| 6.6.1 | No credentials are stored in ConfigMaps, image layers or manifests in Git. | Must | Secret scan of repositories, images and ConfigMaps. |
| 6.6.2 | Secrets come from an external store through the Secrets Store CSI Driver or an equivalent operator, mounted as files rather than environment variables where possible. | Should | Workload review. |
| 6.6.3 | Images come from approved registries and are referenced by sha256 digest or verified by signature at admission. | Must | Admission policy (ImagePolicyWebhook, a policy engine or the provider's equivalent) rejects an unsigned test image. |
| 6.6.4 | Images are minimal, contain no shell or debug tools in production (use ephemeral debug containers), and set a non-root USER. | Should | Image inspection. |
| 6.6.5 | Images are scanned in CI and in the registry; critical findings block deployment. | Must | Pipeline gate evidence. |
See the Kubernetes Secrets Security Guide and Kubernetes Admission Control Guide.
6.7 Audit logging and detection
| # | Requirement | Level | Verify |
|---|---|---|---|
| 6.7.1 | API server auditing is enabled with an audit policy (--audit-policy-file; with no policy, no events are logged): Metadata level at minimum, RequestResponse for RBAC changes, never request bodies for Secrets. | Must | Audit policy file reviewed; managed: control plane audit logs exported. |
| 6.7.2 | Audit logs are shipped to the SIEM, protected from general access and kept for [12 months]. | Must | SIEM search returns events from the last hour; access list reviewed. |
| 6.7.3 | Alerts exist for: exec into pods, new ClusterRoleBindings, privileged pod creation, Secret reads by unusual identities, anonymous requests. | Must | Test each detection. |
Detection content is in the Kubernetes Audit Log Detection Guide.
7. Threat and framework mapping
| Checklist area | Attack it blocks (MITRE ATT&CK) | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|---|
| 6.1, 6.2 control plane and kubelet | T1609 Container Administration Command | CM-6, SC-7 | PR.PS-01 |
| 6.3 RBAC and tokens | T1552.007 Container API | AC-6 | PR.AA-05 |
| 6.4 Pod Security | T1610 Deploy Container | CM-6, AC-6 | PR.PS-01 |
| 6.5 Network | T1613 Container and Resource Discovery | SC-7 | DE.CM-01 |
| 6.6 Secrets | T1552.007 Container API | SC-28 | PR.PS-01 |
| 6.7 Audit | All of the above | AU-2 | DE.CM-01 |
| 5 Supported versions | Exploitation of unpatched components | CM-6 | ID.AM-08 |
For ISO/IEC 27001:2022, these checks support Annex A controls 8.9 (configuration management), 8.15 (logging), 8.20 (networks security) and 8.24 (use of cryptography). For CIS Controls v8.1, they support safeguard 4.1 (secure configuration process) and Control 8 (audit log management).
8. Exceptions
- Any unmet "must" item needs a written exception naming the cluster, the item, the compensating control, the risk owner and an expiry of no more than [90 days].
- Privileged namespaces (CNI, CSI, monitoring agents) are listed by name in the exception register, not granted cluster-wide.
- Exceptions are reviewed at each sign-off and expire automatically.
9. Compliance and measurement
- CIS Benchmark pass rate: automated scan per cluster, target [95%] of applicable items, with every fail ticketed.
- Pod Security coverage: share of application namespaces enforcing
restricted, target [100%]. - Default-deny coverage: share of namespaces with default-deny ingress and egress.
- Token hygiene: number of pods with a mounted service account token that never call the API, and of legacy token Secrets (target: zero).
- Version currency: clusters on a supported minor version, and days behind latest patch.
- Cluster-admin count: human subjects bound to
cluster-adminoutside break-glass (target: zero standing).
10. Related documents and review
This standard is reviewed every [12 months], when a new CIS Benchmark version is published, after each Kubernetes minor upgrade and after any container security incident. Related documents: [Cloud Security Standard], [Secrets Management Standard], [Vulnerability Management Standard], [Incident Response Plan].
Implementation guidance
- Scan before you change: run the CIS Benchmark scan for your distribution and an RBAC export on the existing cluster to see the real gap.
- Close the exposure items first: public API server, anonymous kubelet, unencrypted Secrets, open metadata endpoint. These are the items attackers find by scanning.
- Introduce Pod Security in warn and audit mode: label namespaces with
warn: restrictedandaudit: restrictedfor [2 weeks], fix violations, then switch toenforceone namespace at a time. Rollback is removing or lowering the enforce label. - Roll out default-deny network policies per namespace with the allow rules observed during a monitoring period; keep the previous policy set in Git so a revert is one commit.
- Shrink RBAC and tokens: remove wildcard grants, set
automountServiceAccountToken: falseon default service accounts and delete legacy token Secrets after confirming nothing uses them via audit logs. - Add image and admission gates in audit mode first, then enforce.
- Codify everything (cluster config, policies, namespaces) in Git so drift is visible and new clusters start compliant.
Small teams on a managed service can meet most of this list with the provider's private endpoint, envelope encryption, workload identity and built-in policy features, plus PSA labels and default-deny policies. Large estates should run a policy engine across clusters and report the metrics in section 9 centrally. A passwordless management console was enough to lose cloud credentials in the Tesla Kubernetes cryptojacking incident, where attackers found AWS keys inside a pod: items 6.1.1, 6.5.3 and 6.6.1 address exactly that chain.
Source baselines
- Kubernetes: Security Checklist
- Kubernetes: Pod Security Standards
- Kubernetes: Role Based Access Control Good Practices
- Kubernetes: Encrypting Confidential Data at Rest
- Kubernetes: Kubelet authentication/authorization
- Kubernetes: Auditing
- NSA and CISA: Kubernetes Hardening Guidance
- CIS: Kubernetes Benchmarks
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Kubernetes Security Guide · Top 10 Kubernetes Security Risks · Kubernetes NHI Security Guide · Kubernetes RBAC Guide