Cluster Hardening and Supply Chain Security

Securing a Kubernetes cluster does not stop at RBAC and NetworkPolicies. A modern attacker targets the entire software supply chain: injecting malicious dependencies, compromising build artifacts, tampering with container images, or exploiting kernel vulnerabilities at runtime.

A robust posture requires Defense in Depth across four stages:

1. Pre-commit / CI: Static analysis and image vulnerability scanning.
2. Registry: Cryptographic image signing (Sigstore / Cosign).
3. Deploy-Time (Admission): Policy enforcement with Validating Webhooks (Kyverno / OPA Gatekeeper).
4. Runtime: Kernel-level behavioral threat detection (Falco).

1. Supply Chain Integrity with Cosign

How do you guarantee that the container image running in production was actually built by your automated pipeline and hasn't been substituted?

Using Cosign (from Sigstore):

• In CI, after building the container image, your runner signs the digest using a KMS key or OIDC keyless signature:

  cosign sign --key k8s://kms-key myorg/app@sha256:abc123...
  

• The signature is stored in the container registry right alongside the image layer.

---

2. Policy as Code: Admission Controllers

Kubernetes provides Dynamic Admission Control via webhooks. Before any resource is committed to etcd, the API Server calls external admission controllers:

• MutatingAdmissionWebhook: Injects defaults (e.g. sidecars, security contexts).
• ValidatingAdmissionWebhook: Enforces organizational guardrails (e.g. "reject any pod from untrusted registries or running as root").

Kyverno vs. OPA Gatekeeper

While OPA Gatekeeper uses the Rego query language, Kyverno is Kubernetes-native, letting you write validation policies directly as standard YAML:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-cosign-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |
                      -----BEGIN PUBLIC KEY-----
                      ...
                      -----END PUBLIC KEY-----

If a developer attempts to deploy an unsigned container or an image from docker.io, the API server rejects the request at the gate.

---

3. Runtime Threat Detection with Falco

Even with immutable images and hardened policies, zero-day vulnerabilities in dependencies (like Log4j) can grant attackers shell access.

Falco (a CNCF graduated project) acts as the security camera for Kubernetes. It runs at the Linux kernel level (via eBPF or a kernel module) and monitors system calls in real time.

When an unexpected event occurs—such as:

• A shell spawned inside an ephemeral production pod (/bin/sh or /bin/bash)
• Sensitive files read (/etc/shadow, /etc/kubernetes/pki)
• An unexpected outbound network connection initiated to known malicious IPs
• A container modifying files in /etc or /bin

Falco instantly emits alerts or triggers automated countermeasures (e.g. terminating the compromised pod or isolating its network interface).

---

Key Hardening Principles

• Implement CIS Kubernetes Benchmark guidelines across control plane and worker nodes.
• Sign images in CI and enforce validation at admission before execution.
• Disallow privileged containers, host networking, and writable root filesystems.
• Monitor kernel system calls at runtime with eBPF to detect zero-day intrusions.