CDK is a statically compiled Go toolkit that evaluates, escapes, and enumerates container environments such as Docker, containerd, and K8s during authorized penetration tests.

CDK, hosted at cdk-team/CDK, is a self-described zero-dependency container penetration toolkit written in Go and released under Apache-2.0. The core design constraint is immediately clear from the README: production containers are frequently slimmed images where curl, wget, gcc, and even basic shell utilities are absent. CDK solves this by shipping as a single static binary that can be dropped into almost any Linux container and run without an OS package dependency, which makes it a pragmatic choice for authorized red-team operators working against deliberately hardened lab targets. The project carries roughly 4.7k stars and a bilingual English/Chinese wiki, signaling an active community around cloud-native offensive security research.

The tool is organized into three cooperating modules, and the architecture tells you a lot about how its authors think about container compromise. The Evaluate module performs reconnaissance, the Exploit module executes specific techniques, and the Tool module bundles network utilities and API clients that replace the missing binaries in minimal images. This evaluation-first workflow mirrors how a careful operator works: enumerate the container's misconfigurations, receive a recommendation, and only then attempt the specific technique that matches the observed weakness.

The entry point for that workflow is cdk evaluate, or cdk evaluate --full to enable sensitive file scanning during information gathering. The output is designed to be actionable rather than exhaustive: the README's sample run shows CDK detecting CAP_DAC_READ_SEARCH and CAP_SYS_MODULE capabilities and a SYS_ADMIN finding flagged as critical, each paired with a suggested cdk run follow-up. From a defensive perspective this output is essentially a misconfiguration report, and blue teams can use the same enumeration logic as a hardening checklist for their own images.

The Evaluate module's coverage table is worth studying in detail because it doubles as a taxonomy of container attack surface. Information gathering includes OS basics, available Linux capabilities and commands, mount points, network namespace details, sensitive environment variables, sensitive processes, and sensitive local files. It also checks for the kube-proxy route-localnet issue tracked as CVE-2020-8558 and performs DNS-based service discovery following the Kubernetes DNS specification. On the discovery side, it enumerates the K8s api-server, service-account tokens, and cloud provider metadata APIs — the three interfaces most commonly abused for lateral movement from a compromised pod.

The Exploit module is where CDK becomes a dual-use instrument, and the README is candid about it: techniques cover container escaping, persistence, and lateral movement. The escape catalog includes named exploits such as runc-pwn for CVE-2019-5736, shim-pwn for the containerd-shim flaw CVE-2020-15257, docker-sock-check and docker-sock-pwn for exposed Docker sockets, docker-api-pwn for the Docker API on port 2375, plus mount-disk, lxcfs-rw, mount-cgroup, abuse-unpriv-userns for CVE-2022-0492, mount-procfs, check-ptrace, and rewrite-cgroup-devices. Each maps to a documented misconfiguration or CVE, which is exactly why defenders should treat this list as a patch-and-harden backlog rather than as an invitation.

Beyond raw escapes, the exploit table branches into post-exploitation categories that follow a recognizable MITRE-style logic. Discovery techniques include service-probe, istio-check for dumping Istio sidecar metadata, and k8s-psp-dump for dumping Pod Security Policies. Remote control is covered by reverse-shell and kubelet-exec. Credential access is the richest category: registry-brute for image registry brute forcing, ak-leakage for access key scanning, etcd-get-k8s-token for extracting cluster tokens from etcd, and k8s-secret-dump for dumping Kubernetes secrets. The presence of these capabilities makes clear that CDK is aimed at full cluster takeover scenarios, not just single-container escapes.

The Tool module is arguably the most generally useful part for legitimate administrators, because it simply restores utilities that slim images lack. It provides vi for file editing, ps for process listing, ifconfig for network information, nc for TCP tunnels, and a parallel TCP port scanner via cdk probe . More interesting are the purpose-built API clients: kcurl speaks directly to the K8s api-server, ucurl makes requests over the Docker unix socket, and ectl enumerates etcd keys without authentication. These clients are what make the rest of the toolkit viable in stripped-down environments.

Installation is deliberately minimal, which is consistent with the zero-dependency philosophy. You download a release binary from the project's GitHub releases page and execute it inside the container you are authorized to test; the basic invocation pattern is ./cdk evaluate --full followed by cdk run against a specific finding. We will not reproduce the README's delivery tips for moving the binary into a compromised container during live engagements, since those are operational details relevant only within an authorized scope you have already established.

Defenders get real value from studying CDK even if they never run its exploit module. Every technique in the catalog corresponds to a detectable or preventable condition: unprivileged user namespaces should be constrained if CVE-2022-0492 matters in your kernel version, the Docker socket and API port 2375 should never be mounted or exposed in workloads, capabilities like SYS_ADMIN and CAP_SYS_MODULE should be dropped by default, and service-account tokens plus metadata API access should be scoped down. CDK's evaluate output is effectively a free audit script for verifying that these controls hold.

From a detection standpoint, CDK's footprint is that of a static Go binary executing local system calls and network probes. Kubernetes audit logs will show unusual requests to the api-server from pods without a corresponding workload identity, etcd and kubelet activity may appear anomalous, and endpoint tooling can flag the binary's execution of probe scans against cluster CIDR ranges. Because the README explicitly lists which exploits run in thin containers, defenders can prioritize alerting on the prerequisites — exposed sockets, mounted host paths, and excessive capabilities — rather than on the tool's signature.

The project's own legal disclaimer is unambiguous: using CDK to attack targets without prior mutual consent is illegal, and the tool is for security testing purposes only. That framing matches how this writeup should be read — CDK is a well-organized, well-documented compendium of container and Kubernetes attack techniques that belongs in the toolbox of authorized penetration testers, and equally in the reference library of the engineers responsible for making sure none of its findings apply to production clusters.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• exploitarium for consolidating public vulnerability research and PoC archives


• Viper for adversary simulation and red team operations