# Kubernetes Review Map — CKS Domains and Modern Attack Paths

> **Intro:** Public Kubernetes security guides are most useful when they provide a **review structure**, not just a pile of commands. This page translates a CKS-style domain model and a modern attack-vector catalog into an enterprise Product Security review map: what to inspect first, what controls matter most, and where the deeper KB pages already live.
>
> **What this page includes**
>
> * a Kubernetes security review model organized around the major CKS domains
> * a short list of attack paths that deserve explicit review in 2026
> * a practical minimum operating stack for preventive, detective, and investigative control layers
> * snippet and cross-link guidance into the rest of this KB

## Why use a CKS-style map inside a Product Security KB

A certification map is not the goal. The value is that it gives teams a memorable review shell covering:

* cluster setup and hardening;
* system hardening;
* workload and microservice restrictions;
* supply-chain trust;
* monitoring, logging, and runtime response.

That is close to how platform teams actually divide ownership.

## Domain map translated into security review work

| Review domain                             | What to ask first                                                      | Controls that usually matter most                                                                                   | First evidence to retain                                             | First KB page                                                                                                                                           |
| ----------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Cluster setup and hardening               | is the control plane and network shape safe by default?                | API server hardening, audit policy, ETCD protection, ingress exposure review, network policies, benchmark alignment | cluster baseline review, audit policy, exposed entry-point inventory | [Kubernetes Security Baseline](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-security-baseline.md)                                   |
| Cluster hardening and access              | can operators, workloads, or namespaces do more than they should?      | RBAC cleanup, namespace boundaries, service-account scoping, kubelet hardening, anonymous-access review             | RBAC diff, privileged binding review, kubelet config review          | [Kubernetes API Access Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-api-access-hardening.md)                             |
| System hardening                          | how much host or runtime trust is available to a compromised workload? | node baseline, kernel controls, seccomp/AppArmor, runtime isolation, reduced host attack surface                    | node baseline, runtime profile settings, exception list              | [Kubernetes Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-hardening.md)                                                   |
| Minimize microservice vulnerabilities     | do workloads run with minimal privileges and clean boundaries?         | Pod Security Admission, securityContext, secret handling, hostPath restrictions, least-privilege network policy     | namespace policy labels, workload exceptions, sensitive mount review | [Kubernetes Top 10 Misconfigurations](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-top-10-misconfigurations.md)                     |
| Supply-chain security                     | can untrusted artifacts, manifests, or policies enter the cluster?     | image scanning, SBOM, signing, admission policy, approved registries, CI trust boundaries                           | image digest, signature / attestation record, scanner output         | [Trusted Images, Harbor, and Signing](/cloud-kubernetes-and-infrastructure-security/index-1/trusted-images-harbor-and-signing.md)                       |
| Monitoring, logging, and runtime security | would we know if the cluster were abused after deployment?             | audit logging, runtime detection, cluster telemetry, investigation workflow, cloud signal integration               | alert trail, audit events, runtime detections, incident notes        | [Runtime Investigation Playbook for Kubernetes and Containers](/cloud-kubernetes-and-infrastructure-security/index-1/runtime-investigation-playbook.md) |

## Attack paths that deserve explicit review in 2026

These cases are repeatedly missed because they sit between “baseline hardening” and “actual attacker workflow”.

| Attack path                                                | Why teams miss it                                                   | First preventive controls                                                                                    | First detective / review controls                                    |
| ---------------------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------- |
| Kubelet anonymous or weak auth exposure                    | platform teams assume kubelet is internally safe by default         | disable or tightly control anonymous auth, require kubelet authn/authz, network restrict node APIs           | node exposure review, kubelet config audit, API access logs          |
| Overprivileged service accounts and token projection abuse | service accounts accumulate privileges over time                    | explicit service accounts, minimal RBAC, token audience and lifetime discipline, avoid unnecessary automount | token usage review, who-can checks, privileged binding review        |
| Ephemeral debug containers and `exec` abuse                | troubleshooting paths bypass normal deploy review                   | restrict who can debug or exec, review break-glass process, log debug usage                                  | audit `exec`, `attach`, and debug activity; incident review workflow |
| HostPath and privileged workload escape paths              | operational shortcuts become permanent                              | Pod Security Admission, admission policy, exception tracking, host mount review                              | privileged workload inventory, namespace exception review            |
| Cloud metadata service abuse from pods                     | cloud identity is treated as “outside Kubernetes”                   | metadata restrictions, workload identity, network egress controls, namespace isolation                       | egress review, unusual credential use, cloud IAM anomaly review      |
| ImagePullSecrets theft and registry credential reuse       | registry access is broader than needed                              | avoid broad shared pull secrets, use workload identity where possible, namespace separation                  | secret inventory, secret mount review, registry access logs          |
| Persistent volume data exposure                            | storage reuse and orphaning are treated as operations-only issues   | PVC lifecycle discipline, access mode review, encryption and sanitization process                            | orphaned volume review, storage inventory, data exposure tabletop    |
| Admission bypass or inconsistent policy layers             | teams deploy PSA, Kyverno, and Gatekeeper without ownership clarity | one clear policy stack design, namespace policy labels, exception workflow, test coverage for policy         | policy drift review, denied-event review, exception registry         |

## A practical minimum Kubernetes security stack

### Early / minimum stack

* **Pod Security Admission** for baseline workload restriction
* **Trivy** or equivalent for image and config scanning
* **Kube-Linter** or equivalent for manifest linting
* **Kubescape** or equivalent for posture and benchmark visibility
* **Falco** or **Tetragon** for runtime detection once ownership exists
* **Audit logging** exported off-cluster

### Better operating stack

Add:

* **Kyverno** or **OPA Gatekeeper** for policy beyond PSA
* **Cilium** or **Calico** with network-policy ownership
* **Cosign** or equivalent signing / verification flow
* **RBAC analysis tools** such as `kubectl-who-can` or `rakkess`
* **forensics helpers** and a written runtime investigation workflow

## Snippets

* [Namespace PSS labels and Kyverno starter](https://github.com/D3One/Product-Security-Gitbook/blob/main/snippets/k8s/namespace-pss-labels-and-kyverno-starter.yaml)
* [Kubernetes tooling cheatsheet](https://github.com/D3One/Product-Security-Gitbook/blob/main/snippets/k8s/kubernetes-tooling-cheatsheet.md)
* [Runtime investigation command pack](https://github.com/D3One/Product-Security-Gitbook/blob/main/snippets/k8s/runtime-investigation-command-pack.md)

## Related pages

* [Kubernetes Security Baseline](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-security-baseline.md)
* [Kubernetes Top 10 Misconfigurations](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-top-10-misconfigurations.md)
* [Kubernetes Risks and Measures Catalog](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-risks-and-measures-catalog.md)
* [Kubernetes Security Tooling Map and Standards](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-security-tooling-map-and-standards.md)
* [Network Policy Patterns](/cloud-kubernetes-and-infrastructure-security/index-1/network-policy-patterns.md)
* [OPA and Policy Enforcement](/cloud-kubernetes-and-infrastructure-security/index-1/opa-and-policy-enforcement.md)
* [Kyverno Deep Pages](/cloud-kubernetes-and-infrastructure-security/index-1/kyverno-deep-pages.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-review-map-cks-domains-and-attack-paths.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.