CKS — Cluster Hardening

2 minute read

Domain 2 — Cluster Hardening (15%)

Cluster Hardening is the second domain of the CKS exam and carries 15% of the total weight. This domain focuses on locking down the Kubernetes control plane itself — API server access, RBAC policies, ServiceAccount hygiene, upgrade cadence, and audit logging.

Unlike CKA where you configure the cluster, CKS expects you to secure it. Every API server flag, every RBAC binding, and every auto-mounted token is a potential attack surface.

What This Chapter Covers

# Topic Focus Area Link
1 Restrict API Access API server flags, auth modes, admission controllers, TLS Restrict API Access
2 RBAC Best Practices Least privilege, dangerous permissions, audit commands RBAC Best Practices
3 ServiceAccount Security Token auto-mount, bound tokens, per-workload SAs ServiceAccount Security
4 Upgrade Frequency CVE exposure, version support window, upgrade strategy Upgrade Frequency
5 API Server Audit Configuration Audit policy levels, log/webhook backends, policy YAML API Server Audit
6 Hands-On Lab Practical exercises covering all cluster hardening topics Cluster Hardening Lab

CKS Exam Relevance

The Cluster Hardening domain tests your ability to:

  • Restrict access to the Kubernetes API — Understand authentication, authorization, and admission control mechanisms and how to configure them securely.
  • Use Role-Based Access Controls — Design and audit RBAC policies that follow least-privilege principles.
  • Manage ServiceAccounts — Prevent unnecessary token exposure and restrict SA permissions.
  • Stay current with upgrades — Understand why running outdated versions is a security risk and how the version support policy works.
  • Configure audit logging — Write audit policies that capture security-relevant events without flooding storage.

Threat Model Context

┌─────────────────────────────────────────────────┐
│              Kubernetes API Server               │
│                                                  │
│  ┌──────────┐  ┌──────────────┐  ┌───────────┐  │
│  │  AuthN   │→ │   AuthZ      │→ │ Admission │  │
│  │          │  │  (RBAC/Node) │  │ Control   │  │
│  └──────────┘  └──────────────┘  └───────────┘  │
│                                                  │
│  Attack surfaces:                                │
│  • Unauthenticated access (anonymous auth)       │
│  • Over-privileged RBAC bindings                 │
│  • Auto-mounted SA tokens in compromised Pods    │
│  • Unpatched CVEs in outdated versions           │
│  • Missing audit trail for forensic analysis     │
└─────────────────────────────────────────────────┘

Each topic in this chapter addresses one or more of these attack surfaces.

Prerequisites

This chapter assumes you are comfortable with:

  • Kubernetes API server architecture and static Pod manifests
  • RBAC concepts (Role, ClusterRole, RoleBinding, ClusterRoleBinding)
  • ServiceAccounts and their relationship to Pods
  • kubeadm cluster operations (init, upgrade)
  • Reading and editing API server flags in /etc/kubernetes/manifests/kube-apiserver.yaml

How to Use This Chapter

  1. Read each topic page — Understand the security rationale and configuration details.
  2. Practice the YAML and commands — Every example is designed to work on a kubeadm-based cluster.
  3. Complete the Hands-On Lab — The final page ties all topics together with practical exercises.
  4. Test yourself — Each page has 5 practice questions at the end.

Start: Restrict API Access →

Previous Up Next
System Hardening CKS Home Restrict API Access

Updated:

You may also enjoy