Cluster Setup and Hardening
Required knowledge for the CKS certification.
Last reviewed: — verified against Kubernetes 1.36.
Securing a Kubernetes cluster begins with a hardened configuration across its core components. This page is the head reference for the two highest-weighted domains of the CKS exam — Cluster Setup (15%) and Cluster Hardening (15%) — covering the API server, etcd, network, nodes, pods, RBAC, secrets, and configuration validation. Each linked article maps to a concrete attack surface, with mitigation guidance and tooling examples.
Following these practices reduces the risk of compromise, supports defense-in-depth, and helps meet compliance frameworks such as the CIS Kubernetes Benchmark.
Why Cluster Hardening Matters
The Kubernetes control plane is the single highest-value target in any cluster. A compromised API server, kubelet, or etcd instance gives an attacker cluster-wide privileges that no workload-level control can recover from. The articles below cover the controls that bound that blast radius:
- API server flags that close anonymous-auth and weak authentication paths
- etcd encryption-at-rest with KMS v2
- Default-deny NetworkPolicy and CNI selection
- Pod Security Admission and admission-time policy enforcement
- Identity-aware RBAC scoped to the smallest possible verb × resource × namespace
- Secret storage that does not depend on plaintext base64 in
etcd
Treat each of the eight sections below as a checklist when bootstrapping a cluster or auditing an existing one.
Hardening Domains at a Glance
Each subsection on this page maps to a well-defined attack surface. The table below summarises the primary control and where to read more.
| Domain | Primary Risk | Key Control | Reference |
|---|---|---|---|
| API Server Security | Anonymous or weak authentication, missing admission control | --anonymous-auth=false, OIDC, admission webhooks | API Server Mitigation |
| Control Plane Security | etcd compromise leaks every Secret | KMS v2 encryption, mTLS, restricted etcd peers | etcd Security |
| Network Security | Lateral movement, ingress hijacking | Default-deny NetworkPolicy, CNI with policy support | Network Policies |
| Node Security | Kubelet API exposure, host compromise | Restricted kubelet authn/authz, hardened OS | Kubelet Security |
| Pod Security | Privileged escapes, host mounts | Pod Security Admission restricted, seccomp, AppArmor | Pod Security Standards |
| RBAC and Identity | Over-broad ServiceAccounts and bindings | Least-privilege RBAC, disable token automount | Insecure RBAC Mitigation |
| Secrets Management | Plaintext Secrets in Git or etcd | KMS v2, external secret stores, encrypted Git stores | Secrets Mitigation |
| Configuration Validation | Misconfigured manifests reaching production | Pre-merge linting, admission policy | Kubescape |
CIS Benchmarks
Use CIS Benchmarks to validate your cluster's security posture:
API Server Security
Harden the Kubernetes API server to reduce exposure and control access:
- Compromised API Server Mitigation
- Misconfigured Admission Controllers Mitigation
- OPA / Gatekeeper
- Kyverno
- Restricting Anonymous API Server Access
Control Plane Security
Protect the cluster's core components and maintain data integrity:
Network Security
Control traffic flow, minimize exposure, and secure ingress/egress:
- DDoS Mitigation
- DNS Security
- Egress Control
- Exposed Dashboard Mitigation
- Ingress Security
- Network Policies
- Service Mesh Security
- Traffic Hijacking Mitigation
- Kube-Hunter
- Cilium
- Calico
- Kong
CNI for Network Policy: Cilium vs Calico
| Aspect | Cilium | Calico |
|---|---|---|
| Data plane | eBPF (kernel-level) | iptables, eBPF (optional), or VPP |
NetworkPolicy support | Native + CiliumNetworkPolicy (L3/L4/L7) | Native + GlobalNetworkPolicy |
| L7 policy | HTTP, gRPC, Kafka, DNS-aware | DNS-aware via Calico Cloud / Enterprise |
| Identity model | Cilium identities (label-based) | Endpoints + selectors |
| Observability | Hubble (built-in) | Calico flow logs (Enterprise) |
| Service mesh | Cilium Service Mesh (sidecarless) | Integrates with Istio / Linkerd |
| Best fit | eBPF-first stacks, L7-aware policy, Hubble visibility | Mature operations, mixed bare-metal / cloud, simpler model |
Read more: Cilium · Calico · Network Policies
Node Security
Secure the infrastructure running your workloads:
Pod Security
Enforce strict security boundaries within workloads:
- AppArmor Profiles
- Compromised Sidecars Mitigation
- Container Escape Mitigation
- CSI Driver Mitigation
- Pod Sandboxing
- Pod Security Standards
- Seccomp in Pods
- Unrestricted hostPath Mitigation
- KubeAudit
- Controlling Supplemental Group IDs with SupplementalGroupsPolicy
- Removing gitRepo Volumes in Kubernetes
- User Namespaces in Kubernetes
Pod Admission: Pod Security Admission vs External Policy Engine
| Aspect | Pod Security Admission (built-in) | Kyverno / OPA Gatekeeper |
|---|---|---|
| Distribution | In-tree, ships with the API server | Add-on (Helm chart, controllers) |
| Configuration | Namespace labels (pod-security.kubernetes.io/...) | CRDs (ClusterPolicy, ConstraintTemplate) |
| Scope | Pod spec only | Any Kubernetes resource |
| Profiles | privileged, baseline, restricted | Arbitrary policy logic (YAML / Rego / CEL) |
| Mutation | None | Yes (Kyverno, Gatekeeper assigners) |
| Best fit | Baseline guardrail with zero ops cost | Custom policy, mutation, image verification |
Most production clusters run both — PSA provides the always-on baseline, and a policy engine layers on the rules PSA cannot express. See the head-term Kyverno vs Gatekeeper comparison for a deeper engine-level breakdown.
RBAC and Identity
Use identity-aware access controls to enforce least privilege:
Secrets Management
Protect sensitive credentials and reduce the blast radius of compromise:
Encrypted-at-rest Git Workflow: Sealed Secrets vs Mozilla SOPS
| Aspect | Sealed Secrets | Mozilla SOPS |
|---|---|---|
| Maintainer | Bitnami | Mozilla / CNCF community |
| Encrypted format | Custom SealedSecret CRD | Standard Secret (or any YAML / JSON) |
| Decryption point | In-cluster controller using a cluster key | Locally or in CI via KMS / age / PGP |
| Key rotation | Controller-managed; resealing required | Drop-in re-encrypt with new KMS key |
| Multi-cluster portability | Per-cluster key, requires resealing | Same encrypted file works across clusters |
| External KMS support | No (uses controller's RSA key) | Yes (AWS KMS, GCP KMS, Azure Key Vault, age, PGP) |
| Best fit | Single-cluster GitOps with one team | Multi-cluster, multi-team, KMS-backed workflows |
Configuration Validation
Validate YAML manifests and infrastructure code for misconfigurations before deployment:
Try It: Live YAML Security Analyzer
Test a workload against the controls above before applying it. The analyzer reports privileged containers, host namespaces, missing securityContext, automounted SA tokens, and other admission-blockers.
Version-Specific Notes (Kubernetes 1.36)
The following cluster-hardening features are GA and should be the default expectation when bootstrapping a new cluster:
- Pod Security Admission — GA since 1.25. Replaces PodSecurityPolicy with
restricted,baseline, andprivilegedprofiles configured via namespace labels. - KMS v2 encryption providers — GA since 1.29. Replaces KMS v1 for at-rest Secret encryption with much higher throughput and key-rotation support.
- Validating Admission Policy — GA since 1.30. CEL-based admission policies live in the API server, eliminating the need to run a webhook for many baseline policies.
--anonymous-auth-config— GA in 1.33. Restricts anonymous requests to specific endpoints (e.g.,/healthz) instead of accepting them globally.- Sidecar containers — GA since 1.33. Init containers with
restartPolicy: Alwaysare the supported pattern for security sidecars (proxies, secret rotators, log shippers). - User namespaces (
hostUsers: false) — GA in 1.33. Maps in-pod root to an unprivileged UID on the host, dramatically reducing escape impact.
Removed APIs to know about:
- PodSecurityPolicy — Removed in 1.25. Migrate to PSA + Kyverno / Gatekeeper.
extensions/v1beta1Ingress — Removed in 1.22. Usenetworking.k8s.io/v1.
Always check the Kubernetes deprecation guide before upgrading.
Hardening Principles for Cluster Setup
Secure by Default
Use distributions and tools that ship with restricted defaults: PSA restricted namespaces for new workloads, default-deny NetworkPolicy in every namespace, encryption at rest enabled before any Secret is created.
Least Privilege
Bind the smallest possible verb × resource × namespace to every ServiceAccount and human user. Disable automountServiceAccountToken on workloads that do not call the API server.
Defense in Depth
Pair admission controls (PSA, policy engines) with runtime detection (Falco, Tetragon) and a hardened control plane (mTLS everywhere, audit logging). One bypassed control should not lead to compromise.
Continuous Verification
Re-run kube-bench and your configuration validator on every cluster change. Treat drift between Git and the cluster as a security event, not an operational one.
Conclusion
Cluster setup and hardening is the foundation of Kubernetes security and the highest-leverage place to invest. Addressing the risks in each layer — from API access to pod isolation — gives you a baseline that the rest of the stack can build on. The articles in this section provide actionable guidance to harden your cluster and protect against the attack vectors catalogued elsewhere on the site.