☸️ Kubernetes Attack Chains for Defensive Preparation

Intro: This page is written for defenders preparing for a pentest, a platform review, or a public exposure increase. The goal is not to dramatize Kubernetes risk. The goal is to show the repeatable sequences attackers use so you can break those sequences early.

What this page includes

common Kubernetes attack-entry points;

recurring escalation and lateral-movement patterns;

cheap defensive breakpoints;

a pre-pentest self-check list for cluster-owning teams.

Why Kubernetes attacks often feel “faster” than expected

Kubernetes compresses several control surfaces into one environment:

workload execution;
service-account identity;
cluster API access;
secrets and config distribution;
image supply chain;
network reachability;
admission and deployment automation.

That means one small application or pipeline weakness can quickly become a platform control problem.

The five most common starting points

Starting point	What the attacker is trying to convert it into
application RCE or SSRF in a pod	service-account token access, metadata access, cluster or cloud identity
exposed Kubernetes interface	direct cluster reconnaissance or privileged action
CI/CD or GitOps compromise	cluster-admin equivalent through delivery trust
poisoned image or registry trust	execution inside trusted workloads
over-privileged kubeconfig, RBAC, or namespace model	fast escalation from “useful” access to “control plane” access

Recurring attack stages

Stage	What the attacker wants	Typical Kubernetes examples
1. foothold	get code execution or credentials	vulnerable app, leaked kubeconfig, exposed dashboard, compromised pipeline
2. identity access	obtain a token or credential with real authority	mounted service-account token, cloud workload identity, GitOps deploy token
3. discovery	map the reachable cluster surface	list namespaces, pods, secrets, roles, service accounts, ingress, nodes
4. privilege expansion	find a stronger identity or execution path	weak RBAC, `create pods`, `exec`, secret read, privileged workload path
5. control / persistence	keep access or alter delivery/runtime state	backdoored image, new CronJob, new secret, altered admission, modified GitOps source

Common attack chains to model against

1) Vulnerable workload → service account → Kubernetes API

This is one of the most common real-world patterns.

Sequence

attacker gains code execution in a pod;
attacker reads the mounted service-account token or uses workload identity;
attacker queries the Kubernetes API for namespaces, secrets, pods, or RBAC data;
attacker looks for permissions that enable stronger movement, such as secret read, pod creation, or workload modification.

Cheap breakpoints

disable automatic service-account token mounting where unnecessary;
scope service-account permissions tightly by namespace and workload purpose;
block easy egress to sensitive internal services where feasible;
monitor unusual API usage from application namespaces.

2) Weak RBAC or “pod creation equals privilege” escalation

Many teams focus on cluster-admin bindings and miss the fact that broad workload creation rights can also become an escalation path.

Sequence

attacker lands on an identity that can create or modify workloads;
attacker launches a more privileged pod, mounts a sensitive volume, or injects a container into an existing trust zone;
attacker reaches node-level, secret-level, or namespace-crossing authority.

What to look for

broad create, patch, or update on pods, deployments, daemonsets, or jobs;
privilege to use privileged containers or sensitive hostPath mounts;
exception-heavy namespaces that bypass normal policy.

Cheap breakpoints

strong admission rules for privileged workloads;
exception governance for hostPath, privileged, hostNetwork, and hostPID use;
RBAC review that treats workload creation as a high-risk capability.

3) CI/CD or GitOps compromise → cluster takeover path

This is often the fastest route in mature environments.

Sequence

attacker compromises a pipeline secret, runner, GitOps token, or repo with deploy authority;
attacker changes manifests, images, Helm values, or deployment automation;
malicious or unsafe configuration is applied by trusted automation;
attacker gains in-cluster persistence or secret access under the appearance of normal release activity.

Cheap breakpoints

isolate runners and protect deployment credentials;
require protected environments or manual approvals for sensitive targets;
sign or attest artifacts where justified;
retain release evidence and deployment approval records.

4) Registry or image-trust abuse

When image trust is weak, the attacker does not need a live cluster exploit first.

Sequence

attacker poisons an image tag, build artifact, or registry path;
cluster pulls the “trusted” artifact automatically;
malicious code executes inside the cluster with whatever identity the workload already has;
attacker pivots to secrets, APIs, internal services, or cloud identities.

Cheap breakpoints

immutable tags or disciplined promotion flow;
signed images and verification where feasible;
registry access review;
image pull policy and provenance discipline.

5) Exposed sensitive interfaces

Some environments make the attacker’s life too easy by exposing control interfaces directly or indirectly.

Examples:

Kubernetes dashboard exposed or weakly protected;
kubelet or metrics endpoints exposed too broadly;
admission or webhook endpoints reachable from untrusted paths;
internal management endpoints unintentionally internet-reachable through ingress or load balancer drift.

Cheap breakpoints

zero-trust the management plane;
restrict who can reach cluster-admin surfaces;
continuously review public exposure and internal routing assumptions;
treat “temporary admin access” endpoints as permanent risk unless removed.

Cross-over with cloud attack paths

Kubernetes incidents often become cloud incidents because workloads or nodes may also hold cloud authority.

Typical bridges:

node or pod access to cloud metadata;
overly broad workload identity;
secret stores or registries reachable from cluster identities;
GitOps or CI identities trusted by both cluster and cloud control planes.

Use this page together with:

Pre-pentest self-check

Use this short list before an external assessment.

Identity and RBAC

Which workloads still mount service-account tokens unnecessarily?
Which roles can read secrets?
Which identities can create or modify workloads?
Which namespaces have exception-heavy RBAC or admin shortcuts?

Pod and runtime posture

Which workloads still run privileged, use hostPath, or bypass normal pod-hardening?
Are exception workloads documented and time-bound?
Is runtime detection enabled for high-value clusters?

Exposure and segmentation

Which ingress, services, or admin interfaces are internet-reachable?
Which namespaces can talk to which others?
Are network policies default-deny or mostly absent?

Delivery trust

Which repos or pipelines can change production manifests?
Are deploy credentials short-lived or static?
Can a compromised runner or GitOps token change multiple environments?

Evidence and detection

Do you retain Kubernetes audit data for privileged actions?
Can you quickly identify who created or changed a workload?
Can you trace image provenance and deployment approval for a suspicious release?

Cheapest high-value defensive moves

Move	Why it pays off quickly
remove unnecessary service-account tokens	reduces the easiest pod-to-API identity path
treat workload creation rights as sensitive	blocks a common escalation pattern
harden privileged workload exceptions	prevents policy bypass from becoming “normal”
protect GitOps and CI/CD trust	closes one of the fastest cluster takeover routes
keep strong audit data for API and deployment actions	makes scoping and response far easier

Companion pages in this KB

Public references

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