Kubernetes Penetration Testing - Do your Kubernetes controls actually block anything?

The most common mistake in Kubernetes security testing is confusing seeing that a control exists with proving that it works. A NetworkPolicy object is present; but does it actually separate traffic? A Pod Security label is visible; but is it enforce, or only warn? An admission webhook is configured; but when it is unreachable, does it reject the request, or quietly accept it?

This playbook rests on a single principle: the job of every test is to turn a declaration into a verified decision. Seeing a label, a policy or a webhook is only the first piece of evidence; the real evidence is a demonstration that the decision is actually applied to a safe test object. What follows sets out how to test each link in the path from a low-privilege starting point to cluster-wide impact, from discovery through identity and authorization, from admission to node security.

---

1. The purpose of the test: which questions must be answered with evidence?

By the end of the assessment, each of these questions must be answerable with evidence rather than assumption. As a researcher, these questions drive your test:

• Who can reach the cluster, from where, and with which identity?
• What can a compromised low-privilege identity actually do?
• Can a breach in one namespace move to other namespaces, the control plane or a node?
• When an unsafe workload is submitted, which layer stops it?
• Through which paths can secrets and tokens be exposed?
• Are network policies merely defined, or do they actually separate traffic?
• Can an untrusted image be run?
• Is suspicious behavior detected and turned into a meaningful alert?
• Can everything created during the test be fully reversed?

Frame every finding by the answer it gives to one of these questions.

---

2. Method first: the safe testing model

You have to settle how you will test before you settle what you will test. The reputation of offensive security is not measured by how far you can go, but by your ability to stop where you should.

2.1 Test levels (S0–S4)

Every activity sits at a level according to the risk it poses to production. Agree the highest level your scope permits, in writing, up front.

S3 and S4 are not part of the default scope. Reading real secrets in production, collecting real tokens, establishing persistence, making changes on a host and consuming resources without control are not done.

2.2 The “stop at the first safe evidence” rule

You do not have to exploit a chain to the end to show its risk. The lowest-impact evidence available is enough:

• For secret access: reading a pre-placed canary value rather than the real one.
• For command execution: showing only the identity and runtime context (at the whoami level).
• For host access: confirming the presence of an approved, harmless canary file rather than reading file contents.
• For network access: receiving a fixed response from a test endpoint rather than application data.
• For privilege escalation: confirming the API decision with a server-side dry run or a temporary scope, rather than creating a durable administrative binding.

The chain stops the moment the evidence exists. Having obtained access is not permission to read more data.

2.3 Stop conditions

Testing stops and the relevant parties are notified if any of the following appears: unexpected restarts, latency or error rates in a production workload; an accidental write outside the test namespace; contact with real business data or a production token; a security control mistaking test traffic for a real attack and starting automated response; a rollback step failing; any possibility of moving into an out-of-scope system.

2.4 The test namespace standard

Use a separate, time-boxed namespace for every check that requires writing. It must carry at least: a unique engagement identifier, a responsible owner, an automatic expiry, a non-production data label, a default-deny network policy, a resource quota and the most restrictive Pod Security profile.

Evaluate a manifest that is expected to be blocked with a dry run first. Create it for real only if the dry run does not produce sufficient evidence and S2/S3 approval exists.

---

3. The evidence model: how do you record a finding?

A screenshot on its own is weak evidence. Fill in this template for every test:

Test ID:
Time (UTC):
Test level (S0–S4):
Test identity / principal:
Request sent or area examined:
Expected safe outcome:
Observed outcome:
Verdict: PASS / FAIL / PARTIAL / BLOCKED / N/A
Evidence summary or digest:
Potential impact:
Rollback step and its verification:

Sensitive values are never written into evidence in plain text: secrets are fully masked, and only the type, resource reference, length and, where needed, a one-way digest are kept. Tokens, certificate private keys and registry credentials never appear in any report.

Verdicts: PASS (safe behavior demonstrated), FAIL (risk safely confirmed), PARTIAL (some layers protect, others only warn), BLOCKED (could not be tested because of permission, access or the test window), N/A (not applicable given the architecture, with a reason). Remember: BLOCKED is not PASS. An area you could not test must stay visible in the report.

---

4. The end-to-end testing flow

From here on, this is the playbook proper, advancing along trust boundaries. Under each heading you get what is tested, how it is safely verified, the expected safe outcome and the finding criterion together.

Phase 0 Derive the trust boundaries

The map comes before the commands. The goal is not an inventory but a single-page trust boundary diagram that answers “which identity can cross which trust boundary?” Place these onto it: API access paths and management networks; identity providers and group mappings; namespace/tenant boundaries; ingress, egress and service-to-service traffic; node pools; the registry and deployment chain; secret sources and workload identity; the audit, event and alert pipeline; backup components.

This map is the reference that will set the severity of every later finding.

Phase 1 Read-only discovery (S1)

Phase 2 The API and control plane access surface

K8S-API-01 Network access boundary. Measure reachability of the API endpoint from the internet, the corporate network and the workload network separately; confirm that the permitted source networks are genuinely narrowed and that the TLS trust chain is valid. Expected: the API is reachable only from defined management paths. Finding: unnecessary public access, a broad source network, an unverifiable certificate.

K8S-API-02 Anonymous access. Compare the responses unauthenticated requests receive on /api, /apis, version, health and resource endpoints; examine the permissions of system:anonymous and system:unauthenticated. Expected: 401/403 for sensitive resources, and only the minimum health information deliberately exposed. Finding: namespace, pod, log, metric or configuration data obtainable without an identity.

K8S-API-03 TLS and client identity. Assess old protocols, weak cipher suites, expired certificates and the risk of shared client certificate use. Finding: a long-lived or shared administrative certificate, an unmanaged certificate lifecycle.

K8S-API-04 Audit coverage. Confirm that authentication failures, RBAC denials, secret access, exec/attach/port-forward, RBAC changes and admission decisions are recorded; look for logs that are immutable or shipped to a separate trust domain. Finding: a critical event not recorded, or not traceable back to a user.

Phase 3 Authentication and RBAC

Looking at role names is not enough in RBAC; roles, bindings, group membership, aggregated roles and impersonation have to be resolved together.

K8S-RBAC-01 Effective permission matrix. Produce a matrix for at least these principals: read-only user, developer, namespace administrator, deployment automation, operator/controller service account, node identity, emergency administrator, unauthenticated user. The matrix must be at the level of verb × resource × subresource × namespace, and must carry these rows separately: pods/exec, pods/attach, pods/portforward, pods/ephemeralcontainers, secrets, serviceaccounts/token, roles/rolebindings, clusterroles/clusterrolebindings, certificatesigningrequests, nodes/proxy, impersonate, escalate, bind.

K8S-RBAC-02 Wildcard roles. Find rules using * for verbs, resources or API groups; assess whether several low-risk permissions combine to produce high impact. Finding: a wildcard that cannot be explained by a business need.

K8S-RBAC-03 Indirect privilege escalation. The real issue here is the risk of the combination, not of an individual permission:

How it is safely verified: use only the test namespace and a low-impact, temporary service account; measure whether it would be accepted with a dry run. Do not bind administrative permission durably.

K8S-RBAC-04 Forgotten bindings. Rate of default service account use, bindings pointing at deleted teams, direct user bindings, the expiry and approval mechanism for emergency permissions, and roles granted to system groups by accident.

K8S-RBAC-05 Token lifecycle. Automatic token mounting should be off for pods that do not need it; look for short-lived, audience-bound, rotatable tokens; check that tokens do not leak into logs, env or volumes. Safe verification: only a synthetic service account and a time-boxed token; a real token is never recorded as evidence.

Phase 4 Admission and policy enforcement

K8S-ADM-01 Pod Security profiles. Examine the enforce/warn/audit labels in every application namespace; record whether the profile version is pinned or tracked to latest. Finding: use of audit/warn only, an absent profile, a broad exception.

K8S-ADM-02 Real blocking test. In an isolated namespace, submit minimal manifests carrying each of the following properties separately, and with a dry run first - if you put several violations into a single manifest you cannot tell which control made the decision:

• privileged: true
• allowPrivilegeEscalation: true
• root user
• host network / PID / IPC
• hostPath
• adding dangerous Linux capabilities
• unconfined seccomp
• a disallowed image source or a mutable tag

K8S-ADM-03 Fail-open and blind spots. Test these: while the admission component is unreachable, is the request accepted (fail-open) or rejected (fail-closed)? Are there blind spots caused by namespace or object selectors? Does behavior differ between CREATE and UPDATE/PATCH? Does the policy change when a controller object is submitted instead of a pod? Are ephemeral containers and subresources covered? Expected: critical policies behave fail-closed and cover equivalent workload-creation paths consistently.

K8S-ADM-04 Exception management. Every exception must have an owner, a rationale, a narrow scope and an expiry date; expired ones must be retested.

Phase 5 Pod and container security

Look for each control read-only in existing manifests, and also pair it with whether a new violation is blocked at the admission layer.

The limit of controlled verification: if you have to confirm acceptance of hostPath or privileged, run the test only on a dedicated node pool; do not mount the host root disk, do not read real host files, do not attempt persistence. Access to a pre-prepared, non-sensitive canary path is sufficient evidence.

Phase 6 Secret and configuration security

K8S-SEC-01 Access graph. Derive which user, group, service account or controller can reach which secret; assess the bulk data effect of the list and watch verbs separately; account for the possibility that an identity able to create workloads reaches another service account’s secret indirectly.

K8S-SEC-02 Usage pattern. Confirm that sensitive values are not written into manifests, ConfigMaps, annotations, command arguments or env; examine the file permissions, mount path and log exposure risk of a secret served through a volume.

K8S-SEC-03 At rest and backup. Encryption of the secret in the data store, rotation of the keys, backups carrying at least the same protection, and separation of restore permission from production write permission.

K8S-SEC-04 Canary verification. In S2, create a unique, synthetic canary secret. Only the test workload that is expected to be allowed should be able to read it; reads from another namespace, another service account and a low-privilege user must be denied. The evidence records that the expected match occurred, not the canary value.

Phase 7 Network security and lateral movement

The presence of a policy is not enough; you have to measure the permission matrix. Set up two synthetic pods and a test service that returns a fixed response.

K8S-NET-01 External exposure. Inventory external IPs, node ports, load balancers and ingress paths; for every external endpoint record the owner, data class, authentication, TLS and rate limit state. Pay particular attention to management panels and metric endpoints.

K8S-NET-02 TLS termination. Assess client→ingress and ingress→backend traffic separately. Finding: TLS only on the external leg, with sensitive backend traffic traveling in the clear.

K8S-NET-03 Default deny. For every application namespace, measure these four cases separately and fill in this matrix:

K8S-NET-04 Selector errors. Empty pod/namespace selectors, a pod left unselected because of a wrong label, a feature the plugin does not support, hostNetwork pods falling outside policy, an over-broad allowance for DNS, and IPv6 being forgotten while IPv4 is enforced.

K8S-NET-05 Metadata access. Measure access from workloads to node and infrastructure metadata endpoints only with a synthetic identity and a request that is not permitted. Real role credentials are not obtained and never written into evidence. Expected: denial at the network or identity layer.

Phase 8 Node, kubelet and container runtime

Start with configuration review at S1; perform S3 verification only on a dedicated node.

K8S-NODE-01 Kubelet access. Network reachability of the read-only and main kubelet endpoints, anonymous authentication, webhook auth/authz, client certificate verification, and the authorization behavior of the pods/log/exec/stats endpoints. Expected: anonymous disabled, requests authenticated, authorization through a webhook, network access limited to the necessary components only.

K8S-NODE-02 Node proxy and debug. Who holds nodes/proxy, node debug and ephemeral container permissions? Report that these can produce higher impact than reading a secret; confirm that debug sessions appear in the audit trail with the user’s identity.

K8S-NODE-03 Runtime socket and host mounts. Look in manifests for mounts of the runtime socket, /proc, /sys, /dev, kubelet directories and the host root path; separate necessary system DaemonSets from application workloads. Finding: a socket or broad host directory mount in an application namespace.

K8S-NODE-04 OS hardening. Patch level, minimum packages and services, file permissions, kernel security settings, direct management access, disk encryption, and a dedicated node pool for privileged workloads.

K8S-NODE-05 Node identity and boundary. The node identity holding only the permissions it needs for its own pod and node objects, NodeRestriction-style limits being active, and a node compromise not turning into the ability to list every cluster secret.

Phase 9 Image and software supply chain

K8S-SC-01 Source and immutability. Approved registries only, digest pinning, mutable tag blocking, and the scope of registry credentials.

K8S-SC-02 Vulnerability management. Correlate the running image inventory with package and OS components; prioritize vulnerabilities in workloads that have internet access, run privileged or use sensitive secrets. Look beyond CVSS to reachability and runtime context.

K8S-SC-03 Provenance and signature. It must be possible to trace which pipeline, source revision and build identity produced an image; an unsigned artifact, or one signed by an unexpected identity, must be shown to be rejected at admission, and re-tagging must not bypass the policy.

K8S-SC-04 Deployment identity. The CI/CD principal must not be a cluster-wide administrator; it must be able to write only to its target namespace and the resource types it needs; secret read and workload update permissions must not combine unnecessarily; human and automation identities must be separated.

Phase 10 Persistent storage

K8S-STO-01 Access boundary. PVCs being bound to the right namespace and workload, the same volume not being mountable by an unexpected pod, ReadWriteMany use suiting the data model, and local/hostPath volumes being managed as exceptions.

K8S-STO-02 Encryption and snapshots. Disk, snapshot and backup encryption, snapshot permissions, data persistence after a namespace is deleted, and control of restores across environments.

K8S-STO-03 StorageClass. Default StorageClass settings, reclaim policy, volume expansion, mount options and topology constraints.

Phase 11 Observability and detection

Test the ability to see as thoroughly as you test prevention. Generate events with an isolated test identity and measure the alert chain.

K8S-DET-01 Identity/RBAC events. Failed authentication, a forbidden secret read, a forbidden exec, an attempt to create an RBAC binding and an anonymous resource request are generated; whether each turns into a record and an alert is measured.

K8S-DET-02 Risky workload event. Privileged/hostPath/hostNetwork is attempted with a dry run or a request expected to be blocked. Three outcomes are recorded separately: (1) the API decision, (2) the audit record, (3) the security alert and the time it takes to arrive. A control that only warns while accepting the object counts as PARTIAL, or FAIL depending on its nature.

K8S-DET-03 Runtime behavior. Harmless canary behaviors are used in an S2 test pod (an unexpected child process, an access attempt to a non-sensitive path, a connection to an unexpected test address); it is checked that detection is visible with user, pod, namespace and image context.

K8S-DET-04 Log integrity. Audit logs being shipped to a separate trust domain, workload identities being unable to delete them, clock synchronization allowing correlation, and sensitive values being masked.

Phase 12 Resilience (S4)

Active tests are in S4 scope; in production, configuration review only is the default.

K8S-RES-01 Resource governance. ResourceQuota, LimitRange, pod CPU/memory/ephemeral limits, pod and object count quotas, PriorityClass/preemption design.

K8S-RES-02 Distribution and disruption tolerance. Critical replicas not being concentrated on a single node or zone, PodDisruptionBudget, anti-affinity/topology spread, and controlled node drain behavior.

K8S-RES-03 Autoscaling abuse. A tenant being unable to cause node growth or a cost attack by creating unlimited pods, HPA metrics being closed to manipulation, and maximum scale and budget limits being defined. In an active load test use a synthetic workload, strict quotas, a short duration and automatic expiry; the test must stop automatically if a health threshold is exceeded.

Phase 13 Multi-tenant isolation

A namespace on its own is not counted as a strong security boundary. Create two synthetic tenants and verify this matrix:

Tenants requiring high trust may need a separate node pool, a separate cluster or additional isolation layers.

---

5. Attack path verification scenarios

Once you can test findings individually, the real skill is chaining them. The goal is not “compromise” but proving the combined effect of several weaknesses with the least possible intervention.

Scenario 1 From a low-privilege user to a workload identity. (1) The low-privilege test user is confirmed able to create pods. (2) Whether it can select a stronger service account is measured with a dry run. (3) If it can, a synthetic service account that reaches only a canary resource is used. (4) The test stops once canary access is confirmed. Root cause: the pod creation permission, the service account usage boundary and admission failing together.

Scenario 2 From workload creation to the node boundary. (1) Each property - privileged, host namespace, hostPath - is attempted with a separate dry run. (2) If acceptance looks likely, the test is repeated only on a dedicated node against a canary host path. (3) The presence of the canary file is confirmed; no command is run, nothing is modified, no real file is read. (4) The objects are deleted immediately. Root cause: RBAC controlled only pod creation, and neither admission nor node isolation limited the impact.

Scenario 3 From a namespace breach to lateral movement. (1) A synthetic pod in Tenant A is the starting point. (2) Access to Tenant B’s synthetic service and canary secret is attempted. (3) The API and network outcomes are recorded separately. (4) Only canary values are used. Root cause: RBAC and NetworkPolicy are different layers; one of them working does not close the gap in the other.

Scenario 4 From the deployment chain to the cluster. (1) The deployment principal’s permitted namespaces and resources are derived. (2) An unapproved but harmless test image is submitted with a dry run. (3) Rejection by signature/provenance and registry policy is expected. (4) It is confirmed that workload update permission does not extend to secrets, RBAC or system namespaces.

Scenario 5 Admission that exists on paper but does not act. (1) The policy object and its selectors are reviewed read-only. (2) A manifest containing a single violation is submitted with a dry run. (3) If only a warning or audit entry is produced while the request is accepted, the control is not reported as “blocking”. (4) The webhook unreachability scenario is evaluated only in an approved test environment.

---

6. Rating findings

Assign severity not by technical property alone, but by scoring five dimensions separately:

The same technical finding is rated differently depending on context: acceptance of a privileged pod may be high in a narrow test namespace and critical where broad user groups can do it in production. A missing NetworkPolicy is medium on its own, and its impact rises where sensitive services are reachable from every namespace without authentication.

---

7. Rollback and closure

The test does not end; it ends when the environment is left as clean as it started. Rollback order: (1) stop active test traffic; (2) delete test controllers and workloads; (3) remove test service accounts, roles and bindings; (4) delete canary secrets, ConfigMaps and temporary volumes; (5) remove NetworkPolicies, quotas and the namespace; (6) revoke time-boxed identities and certificates; (7) confirm that no leftover object carries the test label; (8) compare cluster health, pod restart counts and alarm state against the baseline.

A namespace deletion request being accepted does not mean the rollback is complete. Resources held by finalizers, external load balancers, persistent volumes, snapshots and external identity bindings all have to be checked separately.

Closure criteria: every test recorded with a verdict; reproducible yet safe evidence for every FAIL; the reason written down for every BLOCKED; the absence of test resources verified by two independent methods; sensitive evidence masked; an owner and a target date assigned to each finding; short-term compensating measures defined for critical findings; retest criteria written in measurable form.

---

Closing

The value of a good Kubernetes penetration test does not show in how many commands you ran; it shows in how accurately you modeled the trust boundaries, how safely you proved the real behavior of the controls, and how completely you left the environment as clean as it started.

The most useful report is not a long list of misconfigurations. It is the report that shows under which conditions a low-privilege starting point reaches namespace, node or cluster impact, and where that chain is best stopped. Because in the end what we test is not the existence of a control; it is its decision.

---

This playbook is the framework of the approach the Red in Pulse team follows in Kubernetes penetration testing engagements: a methodology that models trust boundaries accurately, exercises controls through real attack paths with safe verification discipline, and leaves the environment as clean as it started. If you would like your cluster’s decisions - not merely the existence of its controls - tested with this rigor, you can contact us for a scoping conversation.