CIS Kubernetes Benchmark Compliance
SIGHUP Distribution (SD) is compliant with our opinionated implementation of the Center for Internet Security (CIS) Kubernetes Benchmark, ensuring alignment with its core security best practices while adapting to our architectural design principles.
The CIS Kubernetes Benchmark v1.11.0 is our current reference. It provides guidance for establishing a secure configuration posture for the latest released Kubernetes version. The benchmark covers all major cluster areas: control plane components, etcd storage and permissions, worker node configuration, authentication and authorization, network policies, and pod security. Being compliant assures that SIGHUP Distribution clusters are provisioned following vetted security standards, helping protect against common misconfigurations and threats.
🔍 Testing our clusters
To verify and maintain compliance, we integrated Aqua Security’s kube-bench into our release pipelines. kube-bench automatically audits a Kubernetes deployment against the CIS Benchmark by checking API server flags, kubelet configuration, file permissions, and many other checks.
We currently use cis-1.11 kube-bench config, which implements CIS Benchmark checks that target Kubernetes versions from 1.29 to 1.32.
Although not officially supported by the CIS Benchmark v1.11, most recommendations for a secure Kubernetes v1.32 cluster hold true also for a Kubernetes v1.33 cluster.
As part of our validation process, we have carefully reviewed the changes introduced in the latest CIS Benchmark and Kubernetes 1.33 release, ensuring that no relevant control discrepancies or breaking changes are present.
Our testing confirms that kube-bench runs successfully and produces consistent results on Kubernetes 1.33, with no compatibility issues identified.
🏗️ Secure by default for on-premises
Our on-premises installer ships with hardened defaults that implement CIS Kubernetes Benchmark recommendations, aligned with SIGHUP’s architectural choices and cluster-specific configurations. As a result, every on-premises cluster provisioned with our installer meets our CIS-compliant security baseline, validated against our adapted kube-bench profiles.
CIS documentation explicitly states that configuration files and paths can vary by deployment tool and platform, and that references should be adapted to the current environment. We follow this guidance, and the kube-bench validation configs used by our on-premises installer are available here:
SIGHUP kube-bench profiles (on-premises) → sighupio/installer-on-premises/utils/kube-bench.
🛡️ Compliance results overview
The CIS Kubernetes Benchmark covers a wide set of checks across all cluster components.
SIGHUP Distribution ensures that the vast majority of these controls are met out-of-the-box for on-premises clusters.
🔑 Key enforced controls
SIGHUP Distribution guarantees strong defaults that align with CIS recommendations, including:
-
Secure configuration files
Critical Kubernetes component (API server, controller manager, scheduler, kubelet) files (static manifests, configuration files, PKI files) have restrictive permissions (600or700) and correct ownership (root:rootoretcd:etcd). -
Admission control policies
Essential admission plugins such asNamespaceLifecycle,NodeRestriction, andServiceAccountare enabled by default to enforce isolation and security boundaries. -
Audit and logging configuration
Audit logs are enabled with sane defaults for retention, rotation, and size to ensure traceability of key events. -
Worker node security
Kubelet and kube-proxy settings follow best practices, including proper TLS validation, disabled unauthenticated access, and secure file permissions.
These measures collectively reduce the attack surface and enforce a consistent security posture across clusters.
📊 Summary by category
The following table summarizes the kube-bench results that you can expect for a SIGHUP Distribution installation that uses the default configuration. For every Item that does not get a PASS result, we explain the reasoning behind it in the section right below the table.
| Category | PASS | WARN | FAIL | INFO |
|---|---|---|---|---|
| Control Plane | 54 | 2 | 0 | 4 |
| Etcd | 7 | 0 | 0 | 0 |
| Authentication & Authorization | 1 | 1 | 0 | 3 |
| Worker Node | 20 | 2 | 0 | 4 |
| Total | 82 | 5 | 0 | 11 |
⚠️ Accepted warnings
While no critical checks fail, running the test will result in some items marked as WARN or INFO.
WARN items are typically related to controls that require manual intervention or cluster-specific configuration.
These are checks that cannot be enforced automatically and are therefore left to the cluster administrator to review and apply as needed.
INFO items often represent best-practice recommendations (not really scored) or non-actionable checks that fall outside the scope of our distribution.
Here's a more detailed list of the mentioned items
| ID | Check (summary) | Status | Motivation |
|---|---|---|---|
| 1.1.7 | Ensure correct permissions on etcd pod manifest | INFO | No pod specification file, since etcd runs as systemd service in our cluster |
| 1.1.8 | Ensure correct ownership on etcd pod manifest | INFO | No pod specification file, since etcd runs as systemd service in our cluster |
| 1.2.1 | Anonymos authentication set to false | INFO | Anonymous authentication used for metrics scraping is safe under proper RBAC |
| 1.2.11 | Admission plugin AlwaysPullImages | INFO | AlwaysPullImages cannot be enforced by default; Waiting for upstream K8s release 1.34, where this issue will be addressed |
| 1.2.27 | Encryption provider config | WARN | The distribution can be configured to enable encryption at rest using the related field encryption configuration. We leave encryption provider selection and key management to the cluster administrator |
| 1.2.28 | Encryption providers properly configured | WARN | The distribution can be configured to enable encryption at rest using the related field encryption configuration. We leave encryption provider selection and key management to the cluster administrator |
| 3.1.1 | Client certificate authentication for users | INFO | Certificate-based auth cannot be disabled by default |
| 3.1.2 | Service account token authentication for users | WARN | Best-practices suggestion, not scored. Policies already in place |
| 3.1.3 | Bootstrap token authentication for users | INFO | Join token usage is limited to node bootstrap only |
| 3.2.2 | Audit policy coverage | INFO | Default audit policy already satisfies benchmark requirements |
| 4.1.3 | Ensure correct permissions on proxy kubeconfig file | INFO | kube-proxy runs as a DaemonSet in the kube-system namespace, not as a local service. No proxy kubeconfig file is present on the nodes |
| 4.1.4 | Ensure correct ownership for proxy kubeconfig file | INFO | kube-proxy runs as a DaemonSet in the kube-system namespace, not as a local service. No proxy kubeconfig file is present on the nodes |
| 4.2.7 | Ensure that the hostname-override argument is not set | WARN | Required for kubeadm-based clusters where system hostname differs from FQDN. Nodes are registered with DNS-aligned names (e.g. master1.k8s.local) and TLS certificates, ensuring secure identity. |
| 4.2.9 | Kubelet TLS certificate and key file | INFO | Rotation of kubelet server certificates is enabled (4.2.11 PASS). Explicitly setting tls-cert-file and tls-private-key-file is unnecessary and would conflict with auto-rotation |
| 4.2.14 | Ensure that the seccomp-default parameter is set to true | INFO | OS management is out of scope. Core system pods already run with the RuntimeDefault seccomp profile, which provides baseline syscall filtering from the container runtime |
| 4.2.15 | Ensure that the IPAddressDeny is set to any | WARN | New check introduced in CIS 1.11. Not yet adopted in SD on-premises installer, as it requires explicitly managing kubelet’s allowed IPs (API server, node, pod subnets). Will be evaluated and addressed in future releases. |
We decided to exlude section 5 of the CIS Benchmark: Kubernetes Policies. These checks cover workload specific governance aspects (RBAC usage, Pod Security Standards, NetworkPolicies, Secrets management, etc.) that cannot be enforced generically by the installer. Instead, they are left to the cluster administrator to implement, according to context-specific requirements.
✅ Passed CIS Controls
Below is the complete list of CIS Benchmark checks successfully passed by SIGHUP Distribution.
🕹️ Control Plane
| ID | Description |
|---|---|
| 1.1.1 | Ensure that the API server pod specification file permissions are set to 600 or more restrictive |
| 1.1.2 | Ensure that the API server pod specification file ownership is set to root:root |
| 1.1.3 | Ensure that the controller manager pod specification file permissions are set to 600 or more restrictive |
| 1.1.4 | Ensure that the controller manager pod specification file ownership is set to root:root |
| 1.1.5 | Ensure that the scheduler pod specification file permissions are set to 600 or more restrictive |
| 1.1.6 | Ensure that the scheduler pod specification file ownership is set to root:root |
| 1.1.9 | Ensure that the Container Network Interface file permissions are set to 600 or more restrictive |
| 1.1.10 | Ensure that the Container Network Interface file ownership is set to root:root |
| 1.1.11 | Ensure that the etcd data directory permissions are set to 700 or more restrictive |
| 1.1.12 | Ensure that the etcd data directory ownership is set to etcd:etcd |
| 1.1.13 | Ensure that the default administrative credential file permissions are set to 600 |
| 1.1.14 | Ensure that the default administrative credential file ownership is set to root:root |
| 1.1.15 | Ensure that the scheduler.conf file permissions are set to 600 or more restrictive |
| 1.1.16 | Ensure that the scheduler.conf file ownership is set to root:root |
| 1.1.17 | Ensure that the controller-manager.conf file permissions are set to 600 or more restrictive |
| 1.1.18 | Ensure that the controller-manager.conf file ownership is set to root:root |
| 1.1.19 | Ensure that the Kubernetes PKI directory and file ownership is set to root:root |
| 1.1.20 | Ensure that the Kubernetes PKI certificate file permissions are set to 644 or more restrictive |
| 1.1.21 | Ensure that the Kubernetes PKI key file permissions are set to 600 |
| 1.2.2 | Ensure that the --token-auth-file parameter is not set |
| 1.2.3 | Ensure that the --DenyServiceExternalIPs is set |
| 1.2.4 | Ensure that the --kubelet-client-certificate and --kubelet-client-key arguments are set as appropriate |
| 1.2.5 | Ensure that the --kubelet-certificate-authority argument is set as appropriate |
| 1.2.6 | Ensure that the --authorization-mode argument is not set to AlwaysAllow |
| 1.2.7 | Ensure that the --authorization-mode argument includes Node |
| 1.2.8 | Ensure that the --authorization-mode argument includes RBAC |
| 1.2.9 | Ensure that the admission control plugin EventRateLimit is set |
| 1.2.10 | Ensure that the admission control plugin AlwaysAdmit is not set |
| 1.2.12 | Ensure that the admission control plugin ServiceAccount is set |
| 1.2.13 | Ensure that the admission control plugin NamespaceLifecycle is set |
| 1.2.14 | Ensure that the admission control plugin NodeRestriction is set |
| 1.2.15 | Ensure that the --profiling argument is set to false |
| 1.2.16 | Ensure that the --audit-log-path argument is set |
| 1.2.17 | Ensure that the --audit-log-maxage argument is set to 30 or as appropriate |
| 1.2.18 | Ensure that the --audit-log-maxbackup argument is set to 10 or as appropriate |
| 1.2.19 | Ensure that the --audit-log-maxsize argument is set to 100 or as appropriate |
| 1.2.20 | Ensure that the --request-timeout argument is set as appropriate |
| 1.2.21 | Ensure that the --service-account-lookup argument is set to true |
| 1.2.22 | Ensure that the --service-account-key-file argument is set as appropriate |
| 1.2.23 | Ensure that the --etcd-certfile and --etcd-keyfile arguments are set as appropriate |
| 1.2.24 | Ensure that the --tls-cert-file and --tls-private-key-file arguments are set as appropriate |
| 1.2.25 | Ensure that the --client-ca-file argument is set as appropriate |
| 1.2.26 | Ensure that the --etcd-cafile argument is set as appropriate |
| 1.2.29 | Ensure that the API Server only makes use of Strong Cryptographic Ciphers |
| 1.2.30 | Ensure that the --service-account-extend-token-expiration parameter is set to false |
| 1.3.1 | Ensure that the --terminated-pod-gc-threshold argument is set as appropriate |
| 1.3.2 | Ensure that the --profiling argument is set to false |
| 1.3.3 | Ensure that the --use-service-account-credentials argument is set to true |
| 1.3.4 | Ensure that the --service-account-private-key-file argument is set as appropriate |
| 1.3.5 | Ensure that the --root-ca-file argument is set as appropriate |
| 1.3.6 | Ensure that the RotateKubeletServerCertificate argument is set to true |
| 1.3.7 | Ensure that the --bind-address argument is set to 127.0.0.1 |
| 1.4.1 | Ensure that the --profiling argument is set to false |
| 1.4.2 | Ensure that the --bind-address argument is set to 127.0.0.1 |
💾 Etcd
| ID | Description |
|---|---|
| 2.1 | Ensure that the --cert-file and --key-file arguments are set as appropriate |
| 2.2 | Ensure that the --client-cert-auth argument is set to true |
| 2.3 | Ensure that the --auto-tls argument is not set to true |
| 2.4 | Ensure that the --peer-cert-file and --peer-key-file arguments are set as appropriate |
| 2.5 | Ensure that the --peer-client-cert-auth argument is set to true |
| 2.6 | Ensure that the --peer-auto-tls argument is not set to true |
| 2.7 | Ensure that a unique Certificate Authority is used for etcd |
📝 Authentication & Authorization
| ID | Description |
|---|---|
| 3.2.1 | Ensure that a minimal audit policy is created |
🛠️ Worker Node
| ID | Description |
|---|---|
| 4.1.1 | Ensure that the kubelet service file permissions are set to 600 or more restrictive |
| 4.1.2 | Ensure that the kubelet service file ownership is set to root:root |
| 4.1.5 | Ensure that the --kubeconfig kubelet.conf file permissions are set to 600 or more restrictive |
| 4.1.6 | Ensure that the --kubeconfig kubelet.conf file ownership is set to root:root |
| 4.1.7 | Ensure that the certificate authorities file permissions are set to 644 or more restrictive |
| 4.1.8 | Ensure that the client certificate authorities file ownership is set to root:root |
| 4.1.9 | If the kubelet config.yaml configuration file is being used validate permissions set to 600 or more restrictive |
| 4.1.10 | If the kubelet config.yaml configuration file is being used validate file ownership is set to root:root |
| 4.2.1 | Ensure that the --anonymous-auth argument is set to false |
| 4.2.2 | Ensure that the --authorization-mode argument is not set to AlwaysAllow |
| 4.2.3 | Ensure that the --client-ca-file argument is set as appropriate |
| 4.2.4 | Verify that if defined, the --read-only-port argument is set to 0 |
| 4.2.5 | Ensure that the --streaming-connection-idle-timeout argument is not set to 0 |
| 4.2.6 | Ensure that the --make-iptables-util-chains argument is set to true |
| 4.2.8 | Ensure that the eventRecordQPS argument is set to a level which ensures appropriate event capture |
| 4.2.10 | Ensure that the --rotate-certificates argument is not set to false |
| 4.2.11 | Verify that the RotateKubeletServerCertificate argument is set to true |
| 4.2.12 | Ensure that the Kubelet only makes use of Strong Cryptographic Ciphers |
| 4.2.13 | Ensure that a limit is set on pod PIDs |
| 4.3.1 | Ensure that the kube-proxy metrics service is bound to localhost |
Heads-up on future updates
The Kubernetes CIS Benchmark and kube-bench evolve alongside Kubernetes. We track new releases and update our validation and hardening accordingly, ensuring continued compliance.