Have the hardening state of your cluster reviewed? The cluster audit compares your cluster with the CIS Kubernetes Benchmark and the BSI module APP.4.4 and delivers a report with prioritized measures. It is a configuration review, not a penetration test. From €1,490 net one-time, credited against the first month of operations (as of October 2026). View the cluster audit
Kubernetes hardening means: the configuration state of the cluster is defined, testable and documented. This checklist sorts the checks into nine layers. Each layer has a pass criterion, a check with kubectl or kube-bench, and a reference to the CIS Kubernetes Benchmark, the BSI module APP.4.4 and the NIS2 minimum areas. As of October 2026. It checks configuration; it is neither a penetration test nor legal advice.
Contents
- Which standards apply: CIS, BSI and NIS2
- Operations concept: what APP.4.4 requires before go-live
- The checklist: nine layers with pass criteria
- What kube-bench covers and what it does not
- NIS2: which technical evidence the cluster provides
- Our approach at WZ-IT
- Status and methodology
- Further guides
Which standards apply: CIS, BSI and NIS2
CIS Kubernetes Benchmark. Configuration recommendations for the control plane, etcd, worker nodes and policies (CIS). The CIS page lists version 2.1.0 for Kubernetes. kube-bench maps its configuration cis-2.0 to Kubernetes 1.34 and 1.35 (table); for 1.36 and 1.37 a mapping is missing. The configuration cis-2.0 has been in the main branch since 18.08.2026; release v0.16.0 (05.08.2026) and its image do not contain it (newest configuration there: cis-1.12). cis-2.0 requires building kube-bench from main; with the release, set --benchmark cis-1.12. Choose the version yourself and classify deviations manually. The control numbers follow cis-2.0.
BSI IT-Grundschutz. The module APP.4.4 Kubernetes (2023 edition, in German) contains 21 requirements and always applies together with SYS.1.6 Containerization. The module additionally covers planning before go-live and backup of the cluster. The kube-bench configuration cis-2.0 has no control for either.
NIS2. Section 30 paragraph 2 of the BSI Act (in German) implements Article 21 of the NIS 2 Directive (EU) 2022/2555 and names ten minimum areas. It requires appropriate, proportionate and effective measures with documentation (section 30 paragraph 1), but prescribes no tools. Whether an entity falls under NIS2 is for the entity to determine.
Operations concept: what APP.4.4 requires before go-live
The five basic requirements (MUST) frame an operations concept:
| No. | Requirement | Question to check |
|---|---|---|
| A1 | Planning the separation of applications | Which namespaces, clusters and networks separate test and production? |
| A2 | Planning automation with CI/CD | Where CI/CD is used, are lifecycle, roles and permissions, and the protection of secrets planned? |
| A3 | Identity and permission management | Is every action authenticated and authorized, with no anonymous administration? |
| A4 | Separation of pods | Does the node kernel isolate processes, IPC, file system and network of the pods? |
| A5 | Backup of the cluster | Are volumes, configuration, cluster state, etcd, infrastructure applications and registry data backed up? |
The standard requirements A6 to A12 cover, among others, network separation with whitelisting (A7), versioned configuration (A8), service accounts (A9), health checks (A11) and registries (A12). For elevated protection needs, automated auditing against benchmarks (A13), micro-segmentation (A18), high availability (A19) and encrypted etcd data (A20) are added.
The checklist: nine layers with pass criteria
Layer 1: control plane and etcd
Pass if the API server, the kubelet API and etcd are not reachable from the internet (Security Checklist), anonymous requests are rejected, the authorization modes include Node and RBAC, etcd is reachable only with client certificates and its own CA, and the kubelet allows neither anonymous access nor a read-only port (private access: NetBird).
Check: curl -sk -o /dev/null -w '%{http_code}\n' https://<api-server>:6443/api returns 401 if anonymous access is off. 403 means: anonymous is enabled but has no permissions. 200 is a finding. On self-operated control plane nodes, kube-bench checks CIS sections 1 and 2.
Why: Anonymous access is enabled by default as soon as an authorization mode other than AlwaysAllow is in use. The BSI lists inadequate authentication in the control plane as the first threat, because protection mechanisms are not enabled by default in all products.
Standard: CIS 1.2.1, 1.2.6 to 1.2.8, 2.1 to 2.7, 4.2.1, 4.2.4. BSI A3, A20.
Layer 2: access and RBAC
Pass if every cluster-admin binding is assigned to a person or role and justified (CIS 5.1.1), no account belongs to system:masters (5.1.7), no wildcard roles exist (5.1.3), people sign in through OIDC at the identity provider rather than with client certificates or service account tokens (3.1.1, 3.1.2), and the default service account has no permissions and is not used (5.1.5, BSI A9). A dated access review exists.
Check:
kubectl get clusterrolebindings -o json | jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name + ": " + ([.subjects[]? | .kind + "/" + .name] | join(", "))'
kubectl auth can-i --list --as=system:serviceaccount:<namespace>:default -n <namespace>
Why: list and watch on secrets expose their content, and anyone who may create pods reaches the secrets and service accounts of the namespace (RBAC Good Practices).
Standard: CIS 3.1.1 to 3.1.3, 5.1.1 to 5.1.13. BSI A3, A9.
Layer 3: Pod Security
Pass if every namespace carries an enforce label of Pod Security Admission, application namespaces are set to restricted, exceptions at baseline are justified and privileged applies only in named system namespaces. warn and audit at restricted show violations before the switch.
Check: kubectl get namespaces --selector='!pod-security.kubernetes.io/enforce' must be empty. Test a switch with kubectl label --dry-run=server --overwrite ns <namespace> pod-security.kubernetes.io/enforce=restricted (guide).
Why: enforce acts on pods, not on deployments. A violating deployment is created, its pods are rejected, and the reason appears as an event on the ReplicaSet.
Standard: CIS 5.2.1 to 5.2.12, 5.6.3. BSI: APP.4.4 does not name the Pod Security Standards. A4 requires kernel isolation between pods, SYS.1.6.A17 containers without privileges.
Layer 4: network policies
Pass if the CNI enforces NetworkPolicies (CIS 5.3.1), every namespace has a default-deny policy for ingress and, where possible, egress plus named allowances (5.3.2), and access from pods to the cloud metadata API 169.254.169.254 is filtered.
Check: namespaces without a NetworkPolicy:
comm -23 <(kubectl get ns -o name | cut -d/ -f2 | sort) <(kubectl get netpol -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\n"}{end}' | sort -u)
Functional test: a connection from namespace A to a service in namespace B times out.
Why: A NetworkPolicy without an implementing controller has no effect, and without a policy pods are not isolated. A default-deny for egress also blocks DNS, so allow it explicitly.
Standard: CIS 5.3.1, 5.3.2. BSI A7 (prohibit all connections between namespaces, allow the required ones), A18 (within the namespace).
Layer 5: secrets
Pass if --encryption-provider-config is set and the first provider is not identity (CIS 1.2.27, 1.2.28), secrets are mounted as files rather than environment variables (5.4.1), an external secret store has been evaluated (5.4.2), no credentials are stored in images (SYS.1.6.A8), ConfigMaps or Git, and service account tokens are mounted only in pods that need them (automountServiceAccountToken: false, 5.1.6).
Check: read a secret directly from etcd, etcdctl get /registry/secrets/<namespace>/<name> | hexdump -C, with the certificate parameters of the cluster. It is encrypted if k8s:enc: follows the path (guide).
Why: Secrets are base64-encoded and stored unencrypted in etcd by default (Secrets Good Practices).
Standard: CIS 1.2.27, 1.2.28, 5.4.1, 5.4.2. BSI A2 (protection of secrets as part of CI/CD planning), SYS.1.6.A8.
Layer 6: images and supply chain
Container hardening includes the image itself.
Pass if containers do not run as root and contain only what the application needs, images are referenced by digest or verified by signature at deploy time, the pipeline scans images, base images are not deprecated and carry unambiguous version numbers (SYS.1.6.A6). An own registry has personal accounts, encrypted communication, logging and backup (BSI A12).
Check: images without a digest:
kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' | sort -u | grep -v '@sha256:'
Plus the pipeline's dated scan report.
Why: The image behind a tag can be changed in the registry (Security Checklist), a digest cannot.
Standard: CIS 5.5.1 (ImagePolicyWebhook). BSI SYS.1.6.A6, APP.4.4 A12.
Layer 7: logging and audit
Pass if the API server starts with --audit-policy-file, the policy covers security-relevant events (CIS 3.2.1, 3.2.2), logs are stored outside the cluster (SYS.1.6.A7 requires container logs to be stored at least outside the container), the retention period is defined and audit logs are protected from general access.
Check: flags in the API server manifest, with kubeadm /etc/kubernetes/manifests/kube-apiserver.yaml. Spot check: create and delete a test namespace. Both actions must appear in the log target with user and time.
Why: Without --audit-policy-file no events are logged (Auditing).
Standard: CIS 1.2.16 to 1.2.19, 3.2.1, 3.2.2. BSI: APP.4.4 has no requirement for the audit log of the API. A12 names logging of changes to infrastructure applications.
Layer 8: upgrades and patch level
Pass if the minor version is still maintained, the kubelet versions are within the version skew policy (at most three minor versions below the API server, never above it), the control plane certificates do not expire within 30 days, no client calls deprecated APIs and the patch level of the node operating systems is documented. As of 28.10.2026 the project maintains 1.35, 1.36 and 1.37. Version 1.34 ended on 27.10.2026 (Releases).
Check:
kubectl version
kubectl get nodes -o wide
# kubeadm only, on a control plane node
kubeadm certs check-expiration
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis
Why: After the end of support no security fixes are released. Certificates generated by kubeadm are valid for one year by default, the CA certificates for ten years; the metric is described in the deprecation policy.
Standard: CIS has no update control. BSI SYS.1.6.A2 (planning of management over the lifecycle including updates), SYS.1.6.A14 (updating of images).
Layer 9: backup and restore
Pass if the backup contains every item from APP.4.4 A5 (persistent volumes, control plane configuration, cluster state with extensions, etcd, infrastructure applications, registry data), snapshots do not replace it, the target is separate from the cluster, etcd snapshot files are encrypted (etcd documentation) and a restore test is logged with date, duration and result.
Check: etcdctl snapshot save and etcdutl --write-out=table snapshot status snapshot.db, then a restore into an empty environment (Kubernetes backup).
Why: The configuration cis-2.0 contains no control for backup. The BSI classifies backup as a basic requirement and states that snapshots must not replace the backup.
Standard: BSI A5.
What kube-bench covers and what it does not
We counted the kube-bench configuration cis-2.0:
| CIS section | Controls | automated | manual |
|---|---|---|---|
| 1 Control plane (files, API server, controller manager, scheduler) | 60 | 47 | 13 |
| 2 etcd | 7 | 6 | 1 |
| 3 Authentication and logging | 5 | 0 | 5 |
| 4 Worker nodes (kubelet, files, kube-proxy) | 25 | 12 | 13 |
| 5 Policies (RBAC, Pod Security, network, secrets) | 34 | 0 | 34 |
| Total | 131 | 65 | 66 |
A green run therefore says nothing about RBAC, Pod Security, network policies and the handling of secrets, and nothing about the content of the audit policy. The kubectl commands above cover these layers. For control plane checks, the pod from job.yaml has to run on a control plane node (nodeSelector and tolerations). On managed Kubernetes these nodes are not reachable (documentation).
NIS2: which technical evidence the cluster provides
The mapping is our reading aid, not an official mapping. The cluster provides technical evidence; judging appropriateness remains with the entity.
| § 30 para. 2 BSIG | Minimum area | Evidence from the cluster |
|---|---|---|
| No. 1 | Policies on risk analysis and IT security | Operations concept with separation, roles and CI/CD planning (APP.4.4 A1, A2) |
| No. 2 | Incident handling | Audit log in an external target with defined retention |
| No. 3 | Business continuity, backup, recovery | Restore log with date, duration and result |
| No. 4 | Supply chain security | Image provenance (digest, signature check), registry access |
| No. 5 | Maintenance, vulnerability handling | Version list with end of support, scan reports, upgrade logs |
| No. 6 | Assessing effectiveness | Dated kube-bench or audit report with measures list |
| No. 8 | Cryptography | Encryption configuration for secrets, TLS configuration of etcd, certificate list |
| No. 9 | Access control | RBAC export with cut-off date, cluster-admin list with justification |
| No. 10 | Multi-factor authentication | OIDC integration, MFA policy at the identity provider |
No. 7 (training) has no cluster evidence.
Our approach at WZ-IT
The cluster audit compares the cluster with the CIS Kubernetes Benchmark and APP.4.4. Among other things it covers versions and upgrade path, RBAC and service accounts, secrets, network policies, and backup and restore path. The result is a report with findings by priority and recommended measures. The audit is a configuration review without changes to the cluster, not a penetration test.
The cluster audit costs from €1,490 net one-time and is credited against the first month of operations. Managed Kubernetes from €590 net per cluster per month including three worker nodes operates the cluster with monitoring, upgrades, backups with restore test and hardening. Alternatively we implement the measures from the report through Kubernetes support, €120 net per hour without a contract. Prices net, as of October 2026.
Status and methodology
- Status: 28.10.2026, all sources retrieved that day.
- kube-bench count: The files in
cfg/cis-2.0(branch main, as of 05.10.2026) were counted by the labels "Automated" and "Manual". cis-2.0 is not part of release v0.16.0, which thejob.yamlreferences. - CIS: The benchmark PDF is not available without registration. The control numbers follow kube-bench cis-2.0 and may differ in version 2.1.0.
- BSI: APP.4.4 and SYS.1.6, 2023 edition, read in full, requirements named with their number. The 2023 edition of the Compendium has been available since 1 February 2023 (BSI).
- NIS2: Section 30 BSIG read. The evidence table is a reading aid.
- Planning values: The 30 days for certificates are a guideline. The answer 401 or 403 in the API server test reflects the default RBAC rules; custom rules for
system:anonymouschange the result.
Further guides
- Kubernetes go-live checklist - 25 checks as a self-test before production
- Kubernetes backup: the four layers - layer 9 in detail
- Taking over a Kubernetes cluster: audit checklist - the operations side
- Access Kubernetes privately with NetBird - no public API
Cluster review or operations handover? The audit delivers the report, managed Kubernetes implements the measures. Cluster audit · Managed Kubernetes
Further reading: Implementing the CIS Kubernetes Benchmark with kube-bench
