# Kubernetes Risks and Measures Catalog

> **Intro:** Kubernetes security guidance often alternates between giant benchmark lists and one-off blog posts. This page provides a working middle ground: a risk-to-measure catalog that can be used during reviews, hardening plans, and backlog shaping.
>
> **What this page includes**
>
> * a practical taxonomy of Kubernetes risk families;
> * a mapping from risk families to concrete measure families;
> * a five-level review model covering environment, cluster, node, container, and API resources;
> * cross-links into existing KB pages that go deeper on each control area.

## Why this page exists

The most useful thing about a large public risk-and-measure library is not copying every item. It is turning the library into a repeatable review model.

This page does that in three layers:

1. organize risks into reviewable families;
2. map those families to concrete protective measures;
3. point engineers to the right deeper page in this KB.

## The five control levels

Use this page with five infrastructure levels in mind:

* **environment** - development, test, staging, production, and the surrounding delivery context;
* **cluster** - control plane, core services, upgrade policy, ETCD, dashboards, admission controls;
* **node** - host baseline, workload placement, kernel and network control points;
* **container** - image trust, image versioning, container runtime posture, rebuild strategy;
* **API resources** - RBAC objects, service accounts, namespaces, pod security context, labels, kubectl access.

## Main risk families

### 1. Access control failures

Typical examples:

* weak RBAC or over-broad cluster-admin use;
* anonymous API access;
* uncontrolled service-account token exposure;
* unsafe kubectl or kubeadm access;
* namespace and ETCD access problems.

### 2. Configuration and platform-hardening failures

Typical examples:

* missing or weak admission controllers;
* unsafe NodePort exposure;
* privileged pods;
* unsafe static pods;
* overlapping host and container identities;
* weak security contexts.

### 3. Supply chain and image trust failures

Typical examples:

* untrusted images;
* unverified artifacts in images;
* poor image versioning hygiene;
* weak retention and artifact-control policy;
* rebuild and provenance gaps.

### 4. Data and secret protection failures

Typical examples:

* modifiable or over-exposed secrets;
* weak encryption in transit for CNI paths;
* unsafe handling of configuration files and sensitive directories;
* log leakage that turns operations data into sensitive data exposure.

### 5. Operational resilience and observability failures

Typical examples:

* missing audit logs;
* weak logging, monitoring, and alarming;
* lack of regular upgrades;
* resource exhaustion and instability;
* uncontrolled pod placement;
* node-level communication blind spots.

### 6. East-west movement and attack-path failures

Typical examples:

* unrestricted pod-to-pod communication;
* unrestricted command execution and file access;
* container escape paths;
* poor isolation between workloads and nodes.

## Specific attack-path cases to review explicitly in 2026

Large public attack-vector libraries are useful because they name cases that broad hardening pages sometimes blur together. The following cases are worth making explicit during reviews.

| Case                                                 | Why it matters                                                                                                          | First controls                                                                | First deeper page                                                                                                                                       |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Kubelet anonymous or weak authentication exposure    | node APIs can become a stealth admin plane if they are reachable and weakly protected                                   | kubelet authn/authz review, network restriction, node exposure inventory      | [Kubernetes API Access Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-api-access-hardening.md)                             |
| Service-account token projection abuse               | projected tokens are safer than legacy secrets, but still dangerous when RBAC is broad or audiences are not scoped well | minimal RBAC, explicit service accounts, token discipline, automount review   | [Kubernetes RBAC and ABAC](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-rbac-and-abac.md)                                           |
| Ephemeral debug container abuse                      | troubleshooting workflows can bypass normal deployment controls                                                         | restrict debug capability, break-glass process, audit debug activity          | [Runtime Investigation Playbook for Kubernetes and Containers](/cloud-kubernetes-and-infrastructure-security/index-1/runtime-investigation-playbook.md) |
| `exec` / `attach` credential theft                   | shell access is often treated as operations-only, but it is a credential and data-exposure path                         | reduce who can exec, prefer safer debug patterns, log sensitive access        | [Kubernetes API Access Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-api-access-hardening.md)                             |
| HostPath and privileged workload escape paths        | these are still among the fastest routes from workload compromise to node compromise                                    | PSA, Kyverno / Gatekeeper, host mount review, exception registry              | [Kubernetes Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-hardening.md)                                                   |
| Cloud metadata service abuse from pods               | cloud credential theft often begins from a pod, not from the host                                                       | workload identity, metadata restrictions, egress review                       | [Infrastructure and Cloud Security](/cloud-kubernetes-and-infrastructure-security/index.md)                                                             |
| ImagePullSecrets theft and registry credential reuse | registry credentials quietly become high-value secrets                                                                  | reduce shared pull secrets, namespace scope, secret inventory and rotation    | [Trusted Images, Harbor, and Signing](/cloud-kubernetes-and-infrastructure-security/index-1/trusted-images-harbor-and-signing.md)                       |
| Persistent volume data exposure                      | storage reuse and orphaned volumes create real data exposure without a flashy exploit                                   | PVC lifecycle discipline, storage review, encryption and sanitization process | [Kubernetes Security Baseline](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-security-baseline.md)                                   |

These cases should be part of tabletop reviews, platform exception reviews, and cluster redesign work - not just penetration-testing notes.

## Risk-to-measure mapping

| Risk family               | Typical failure mode                                     | Measure family                                                                    | First KB page to use                                                                                                              |
| ------------------------- | -------------------------------------------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Access control            | broad permissions, unsafe tokens, weak admin boundaries  | RBAC, API hardening, namespace discipline, service-account control                | [Kubernetes RBAC and ABAC](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-rbac-and-abac.md)                     |
| Configuration hardening   | privileged pods, weak admission, unsafe exposure         | admission controllers, Pod security controls, securityContext, NodePort limits    | [Kubernetes Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-hardening.md)                             |
| Supply chain and images   | untrusted or unverifiable images                         | image trust, signing, rebuild flow, image versioning, controlled registries       | [Trusted Images, Harbor, and Signing](/cloud-kubernetes-and-infrastructure-security/index-1/trusted-images-harbor-and-signing.md) |
| Data and secrets          | mutable secrets, weak transit protection, config leakage | immutable secrets, encrypted CNI paths, file protection, safer logging            | [Kubernetes Security Baseline](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-security-baseline.md)             |
| Operations and visibility | missing logs, poor monitoring, stale clusters            | audit policy, control-plane logging, upgrades, alerting, resilience checks        | [Runtime Investigation Playbook](/cloud-kubernetes-and-infrastructure-security/index-1/runtime-investigation-playbook.md)         |
| East-west movement        | open network paths and lateral movement                  | deny-all network policy baseline, node and pod isolation, tighter exec/file rules | [Network Policy Patterns](/cloud-kubernetes-and-infrastructure-security/index-1/network-policy-patterns.md)                       |

## Concrete control ideas by category

### Access control measures

* implement granular RBAC instead of role sprawl;
* disable anonymous requests to the API server;
* avoid default service-account token auto-mount where it is not needed;
* restrict kubeadm and high-risk kubectl usage;
* manage namespaces and ETCD access as explicit security boundaries.

### Configuration and hardening measures

* enable and review admission-controller posture;
* limit NodePort usage and prefer safer ingress patterns;
* reduce privileged workloads;
* enforce pod- and container-level securityContext defaults;
* review static pod exposure and host-path usage.

### Supply chain and image measures

* implement container and image security best practices;
* use image versioning that avoids the latest-tag anti-pattern;
* verify artifacts in container images where possible;
* prefer controlled rebuild and promotion workflows over ad-hoc image reuse;
* connect image policy to runtime or admission enforcement.

### Data and secrets measures

* use immutable secrets where they reduce accidental or malicious drift;
* secure Kubernetes configuration files and sensitive directories;
* use CNIs or patterns that support encrypted communication where required;
* treat logs and monitoring data as a data-protection concern, not only an ops concern.

### Operations and observability measures

* implement comprehensive audit-log policy;
* enable control-plane logging that is actually reviewable;
* maintain regular upgrade discipline;
* set logging, monitoring, and alarming expectations explicitly;
* review cluster resilience, backup patterns, and resource limits together.

### East-west movement and isolation measures

* start from deny-all network policy patterns and allow only what is needed;
* use taints, tolerations, and node affinity intentionally;
* reduce unrestricted command execution and file access;
* review pod placement and node-level communication as part of cluster design, not only during incidents.

## A practical review sequence

### Fast 30-minute pass

* check for cluster-admin sprawl;
* check whether default service-account tokens are everywhere;
* check whether there is any real network-policy baseline;
* check whether audit logging exists and is reviewable;
* check whether image trust is policy-driven or wishful thinking.

### Deeper 90-minute pass

* map workloads by trust boundary;
* review admission control, Pod security posture, and security contexts;
* review ETCD, dashboards, and API server exposure;
* review image provenance and artifact verification workflow;
* review upgrade and logging ownership.

### Backlog shaping pass

When writing remediation tasks, avoid giant epics like "secure Kubernetes." Use backlog slices such as:

* disable token auto-mount for selected workloads;
* implement deny-all plus namespace-specific allow rules;
* add control-plane audit logging and retention;
* restrict NodePort usage;
* introduce immutable secrets for selected services;
* define image-signing or image-verification policy for critical services.

## Where this page connects to existing content

Use this page as the catalog, then go deeper with:

* [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 Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-hardening.md)
* [Kubernetes API Access Hardening](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-api-access-hardening.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)
* [Runtime Investigation Playbook for Kubernetes and Containers](/cloud-kubernetes-and-infrastructure-security/index-1/runtime-investigation-playbook.md)
* [AppArmor and Seccomp for Docker](/cloud-kubernetes-and-infrastructure-security/index-1/apparmor-and-seccomp-for-docker.md)

## Common mistakes when using a risk catalog

* treating the catalog as a checklist to satisfy once;
* separating image trust from runtime and admission controls;
* reviewing Kubernetes as if it were only a cluster-hardening topic and not also a delivery topic;
* creating one large hardening epic instead of small, owner-backed remediation slices;
* forgetting that logs, tokens, namespaces, and image metadata all become attack-path material.

\---*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# 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-risks-and-measures-catalog.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.