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:

organize risks into reviewable families;
map those families to concrete protective measures;
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
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
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
`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
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 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
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
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

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
Configuration hardening	privileged pods, weak admission, unsafe exposure	admission controllers, Pod security controls, securityContext, NodePort limits	Kubernetes Hardening
Supply chain and images	untrusted or unverifiable images	image trust, signing, rebuild flow, image versioning, controlled registries	Trusted Images, Harbor, and Signing
Data and secrets	mutable secrets, weak transit protection, config leakage	immutable secrets, encrypted CNI paths, file protection, safer logging	Kubernetes Security Baseline
Operations and visibility	missing logs, poor monitoring, stale clusters	audit policy, control-plane logging, upgrades, alerting, resilience checks	Runtime Investigation Playbook
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

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:

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.