CKS Deep Guide: Cluster Hardening & Runtime Security

TL;DR (Quick Summary)

#

• Exam Prerequisite: You MUST hold an active CKA certification before taking CKS.
• Core CKS Domains:
  • Cluster Setup & Hardening (15%)
  • Cluster System Hardening (15%)
  • Minimize Microservice Vulnerabilities (20%)
  • Supply Chain Security (20%)
  • Monitoring, Logging & Runtime Security (20%)
• Key Tools Tested: Falco (Runtime Security), Trivy (Vulnerability Scanner), kube-bench (CIS Auditing), AppArmor, Seccomp.

1. CKS Security Lifecycle Architecture

#

graph TD
    subgraph Build Phase (Supply Chain)
        TrivyScan["Trivy Image Scan"] -->|Fails on Critical CVE| Registry["Private Registry"]
    end
    
    subgraph Deploy Phase (Admission Control)
        ImagePolicy["ImagePolicyWebhook"] -->|Validates Signatures| APIServer["kube-apiserver"]
        NetworkPolicy["NetworkPolicy Isolation"] -->|Default Deny All| Pods["Workload Pods"]
    end

    subgraph Runtime Phase (Threat Detection)
        Falco["Falco eBPF Kernel Probe"] -->|Detects Shell Spawning| Alert["Security Alert / Kill Pod"]
    end

2. Security Tools Matrix (CKS Exam Essentials)

#

3. Step-by-Step Lab 1: Writing Falco Runtime Security Rules

#

Detect when a developer executes bash or sh inside a running production container.

Step 1: Create a Custom Falco Rule

#

Edit /etc/falco/falco_rules.local.yaml:

- rule: Terminal Shell Spawned in Container
  desc: Detect unauthorized shell execution inside a running container
  condition: container.id != host and proc.name in (bash, sh, zsh)
  output: "Unauthorized Shell Spawned (user=%user.name container_name=%container.name image=%container.image.repository)"
  priority: WARNING

Step 2: Restart Falco and Verify Logs

#

sudo systemctl restart falco
sudo journalctl -u falco -f

4. Step-by-Step Lab 2: Enforcing Strict NetworkPolicies

#

Implement a Default Deny All NetworkPolicy to block all unapproved ingress and egress traffic in namespace finance.

Step 1: Default Deny All Manifest

#

Create default-deny-all.yaml:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: finance
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Step 2: Allow Specific Frontend to Backend Access

#

Create allow-frontend-to-backend.yaml:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: finance
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 5432

5. Step-by-Step Lab 3: Scanning Containers with Trivy

#

Scan nginx:1.18 and report ONLY HIGH and CRITICAL vulnerabilities:

trivy image --severity HIGH,CRITICAL nginx:1.18

Expected Terminal Output:

nginx:1.18 (debian 10.4)
Total: 42 (HIGH: 30, CRITICAL: 12)

+---------------+------------------+----------+-------------------+---------------+
|    LIBRARY    | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |
+---------------+------------------+----------+-------------------+---------------+
| libssl1.1     | CVE-2023-0286    | CRITICAL | 1.1.1d-0+deb10u3  | 1.1.1d-0+deb10u7|
+---------------+------------------+----------+-------------------+---------------+

6. Troubleshooting & Common CKS Errors

#

Error 1: Pod Rejected by Seccomp Profile

#

Symptom: Pod remains in CreateContainerError. Diagnosis: The profile at localhostProfile: profiles/audit.json is missing on the target worker node /var/lib/kubelet/seccomp/profiles/audit.json.

Error 2: API Server Fails Boot After ImagePolicyWebhook Config

#

Symptom: kube-apiserver static pod fails to start after editing /etc/kubernetes/manifests/kube-apiserver.yaml. Diagnosis: Check /var/log/pods/kube-system_kube-apiserver.../kube-apiserver/0.log for invalid path to --admission-control-config-file.

Summary & Next Steps

#

In this guide:

• We created Falco runtime threat detection rules.
• We isolated cluster namespaces using Default-Deny NetworkPolicies.
• We scanned images for critical vulnerabilities using Trivy.
• We debugged Seccomp profiles and Admission Control Webhooks.

Next, we move to Module 3: Docker Deep Series (01 - 05)!