Kubernetes CIS Benchmark: Securing Production Clusters

Why Kubernetes Security Requires Its Own Benchmark

Kubernetes presents a security model that does not map cleanly onto traditional OS or cloud benchmarks. The cluster control plane (API server, etcd, scheduler, controller manager) operates as a set of services with their own configuration, threat model, and failure modes. Worker nodes host workloads but also expose the kubelet, container runtime, and node-level orchestration that have specific attack surfaces. Workload security depends on namespace boundaries, RBAC policies, network policies, pod security standards, and admission controllers. None of these have direct equivalents in OS or cloud-native security models.

The CIS Kubernetes Benchmark addresses this by providing a Kubernetes-specific configuration baseline covering the control plane, worker nodes, and policies. The benchmark is structured to apply to self-managed Kubernetes installations; managed Kubernetes platforms (EKS, AKS, GKE, OpenShift) have their own related benchmarks because the managed provider handles the control plane and the customer is responsible only for workload configuration.

This guide focuses on the CIS Kubernetes Benchmark for self-managed clusters. Subsequent posts cover the EKS, AKS, and OpenShift variants.

Section 1: Control Plane Components

The control plane is the brain of the cluster. Its components run as system services (often as static pods or systemd services) on the control plane nodes. Compromising the control plane gives an attacker full cluster authority.

Critical control plane controls:

API server configuration: the API server is the central control plane entry point. Critical settings include:

`--anonymous-auth=false` (no anonymous access)

`--authorization-mode` set to RBAC and Node (never AlwaysAllow)

`--basic-auth-file` not used (basic auth has no audit trail)

`--insecure-port=0` (disable the insecure-by-design HTTP port)

`--audit-log-path` configured to a persistent location

`--audit-log-maxage`, `--audit-log-maxbackup`, `--audit-log-maxsize` configured for retention

`--service-account-lookup=true` (verify service account tokens against the API)

`--enable-admission-plugins` includes the secure set (NodeRestriction, AlwaysPullImages, etc.)

`--disable-admission-plugins` excludes deprecated plugins

etcd configuration: etcd holds the entire cluster state including secrets. It must be configured with TLS for client and peer communication, with encryption at rest, and with strict access controls.

kube-controller-manager configuration:

`--use-service-account-credentials=true` (per-controller service accounts)

`--profiling=false` (disable the profiling endpoint that leaks data)

`--feature-gates` matched to current secure feature set

kube-scheduler configuration:

`--profiling=false`

`--bind-address=127.0.0.1` (scheduler should not be reachable externally)

The control plane controls are typically set via the static pod manifests on the control plane nodes (`/etc/kubernetes/manifests/`). Kubeadm-installed clusters use specific manifest patterns; other installation methods vary but the same configuration must apply.

Section 2: Worker Node Components

The worker nodes host the kubelet, container runtime, and the workloads themselves. The benchmark addresses kubelet configuration in detail because the kubelet is the most exposed worker-node component:

kubelet configuration:

`--anonymous-auth=false` (no anonymous access to the kubelet)

`--authorization-mode` set to Webhook (defer authorization to the API server)

`--client-ca-file` configured (kubelet authenticates clients via certificates)

`--read-only-port=0` (disable the read-only port that exposes cluster info)

`--protect-kernel-defaults=true` (enforce kernel parameter defaults)

`--make-iptables-util-chains=true` (kubelet manages iptables)

`--event-qps=0` not set (allow events to flow to the API)

`--tls-cert-file` and `--tls-private-key-file` configured (TLS for kubelet API)

`--rotate-certificates=true` (kubelet rotates its own certificates)

`--rotate-server-certificates=true` (server certificate rotation)

`--feature-gates` matched to current secure feature set

The kubelet's TLS configuration is particularly consequential. Untrusted kubelet endpoints have been a recurring source of Kubernetes breaches.

Container runtime configuration: the underlying container runtime (containerd, CRI-O, Docker historically) must be configured with appropriate isolation, image verification, and audit logging.

Section 3: Cluster Policies

The cluster-level policy controls govern how workloads run and what they can access:

RBAC (Role-Based Access Control):

`cluster-admin` role should be used only where required (it grants unconstrained access)

Access to `secrets` should be minimized

The `system:masters` group should not be granted to user accounts

ServiceAccount tokens should not be auto-mounted into pods that do not need them

Network policies:

A default-deny network policy should exist in each namespace

Network policies should specify both ingress and egress rules

Inter-namespace traffic should require explicit policy

Pod Security Standards:

Pod Security Admission should enforce baseline or restricted profiles in production namespaces

Privileged pods should be disallowed in production

Host namespace usage (hostPID, hostIPC, hostNetwork) should be restricted

Container capabilities should be minimized

runAsNonRoot should be enforced where possible

Secrets management:

Secrets should be encrypted at rest via the EncryptionConfiguration on the API server

External secret stores (HashiCorp Vault, cloud KMS-backed secrets) should be considered for production

Secrets should not be exposed via environment variables where files would suffice

Admission controllers:

ValidatingAdmissionWebhook and MutatingAdmissionWebhook should be used to enforce custom policy

OPA Gatekeeper or Kyverno can codify cluster-wide policy as code

Section 4: Audit Logging

Kubernetes audit logging captures every API call against the cluster. Without audit logging, security event reconstruction is impossible.

Audit policy controls:

An audit policy file should exist and be loaded by the API server

The audit policy should log at `RequestResponse` level for sensitive resources (secrets, configmaps, RBAC objects)

The audit policy should log at `Metadata` level for the broader set of resources

Audit logs should be forwarded to a central log store (Elastic, Splunk, Loki, cloud-native)

Audit log retention should align with regulatory requirements

The audit policy is where many clusters under-invest. Default audit policies log too little, and missing audit log forwarding means the data is lost when the control plane node restarts.

Common Kubernetes Configuration Drift

Kubernetes clusters exhibit recurring drift patterns:

RBAC accretion. Permissions granted for specific projects accumulate over time. Service accounts with cluster-admin scope, individual users granted broad permissions, role bindings that exceed need.

Network policy gaps. Namespaces without default-deny network policies. Pods deployed without specific ingress/egress restrictions. Inter-namespace traffic permitted broadly.

Privileged pod creep. Privileged pods deployed for "temporary" troubleshooting and never removed. Pods running as root because the workload was not refactored to support non-root.

Image source drift. Deployments referencing images from public registries without image verification. Outdated base images carrying known CVEs.

Secret exposure. Secrets mounted as environment variables that leak via process listings or crash dumps. Secrets stored in plaintext in Helm charts checked into source control.

Audit policy minimization. Audit policy reduced to lower log volume, with sensitive resource access dropping out of the audit trail.

etcd backup gaps. etcd backups configured initially but not validated; recovery never tested.

EKS, AKS, GKE, and OpenShift Specifics

Managed Kubernetes platforms shift control plane responsibility to the provider. The CIS benchmarks for EKS (CIS Amazon EKS Benchmark), AKS (CIS Microsoft AKS Benchmark), GKE (CIS Google GKE Benchmark), and OpenShift cover the customer-controlled portions:

Worker node configuration

RBAC and policy controls

Network configuration

Workload security

Logging and audit

Cluster add-ons

For managed clusters, the control plane controls are out of scope (the provider handles them) but the customer-side controls are typically more numerous because the platform exposes additional configuration points.

CISGuard supports the EKS, AKS, and OpenShift benchmarks as separate scanners with provider-specific control coverage.

How Continuous Compliance Supports Kubernetes

Kubernetes clusters are not assessable through manual audit at any meaningful scale. A production cluster has thousands of resources, hundreds of namespaces, and continuous change driven by CI/CD deployments. Configuration drift cannot be controlled by periodic review.

Continuous compliance scanning provides:

Per-cluster compliance against the appropriate benchmark

Real-time drift detection when configuration degrades

Per-resource detail identifying the specific resource and control violated

Multi-cluster rollup for organizations operating many clusters

Multi-framework mapping showing each control's coverage of NIST 800-53, ISO 27001, SOC 2, HIPAA, PCI DSS, FedRAMP

The shift from periodic to continuous is especially important for Kubernetes because the rate of change exceeds the rate of human review.

How CISGuard Supports Kubernetes CIS Benchmark Compliance

CISGuard's Kubernetes scanner evaluates the full CIS Kubernetes Benchmark with patterns suited to production cluster operations:

Self-managed Kubernetes coverage with control plane and worker node controls

AKS, EKS, and OpenShift coverage through separate scanners

Multi-cluster scanning with organizational rollup

Continuous scanning at configurable cadence

Drift detection with timestamped baseline comparisons

Multi-framework mapping showing how each Kubernetes control satisfies NIST 800-53, ISO 27001, SOC 2, FedRAMP, CMMC, HIPAA, PCI DSS

Air-gapped support for clusters operating without internet connectivity

See Kubernetes CIS Benchmark coverage in CISGuard or request a Kubernetes security assessment.