PE-CRI
crictl
CLI for any CRI-compatible runtime, used to inspect and debug pods and containers at the Kubernetes node level.
OVERVIEW
crictl (github.com/kubernetes-sigs/cri-tools) is the official CLI for the Container Runtime Interface (CRI), the API Kubernetes uses to talk to whatever container runtime a node actually runs — containerd, CRI-O, or another CRI implementation. Because it speaks the CRI API rather than a runtime-specific one, the same commands work regardless of which engine is installed, which makes it the go-to tool for post-exploitation on a Kubernetes worker node when you don't yet know (or don't want to assume) what's underneath.
It mirrors `docker` and `kubectl` closely enough to be immediately usable — `crictl pods`, `crictl ps`, `crictl inspect`, `crictl logs` — and surfaces details, like the exact image digest a pod is running or mounted host paths, that are sometimes hidden a layer up from the Kubernetes API itself.
USE CASES
Practical use cases
- 01
Enumerating pods and containers directly on a compromised Kubernetes node, regardless of the underlying runtime.
- 02
Inspecting mounts, environment variables, and image digests that may not be visible via `kubectl` alone.
- 03
Pulling logs from a container at the node level when API server access is unavailable or restricted.
- 04
Cross-checking node-level container state against what the Kubernetes control plane reports.
QUICK START
After landing on a Kubernetes worker node, to enumerate pods/containers at the CRI level regardless of which runtime (containerd, CRI-O) is underneath.
- Confirm node-level access and any container inspection/breakout work is explicitly within the engagement scope.
- Verify crictl is available (it ships by default on many Kubernetes node images) or install it matching the cluster CRI version.
- Point it at the node CRI socket, e.g. `--runtime-endpoint unix:///run/containerd/containerd.sock`, if not already configured.
- Enumerate with `crictl pods` and `crictl ps -a`, then `crictl inspect` a specific container of interest.
sudo crictl --runtime-endpoint unix:///run/containerd/containerd.sock ps -aBEFORE YOU RUN IT
What to check before running it
Node-level CRI access generally exposes every pod scheduled to that node, including workloads belonging to other tenants or teams — handle findings under the engagement's data-handling rules.
Using crictl to modify or stop containers affects real workloads on that node — treat it as a host-level action requiring the same authorization as any other node-level tooling.
Behavior and flags can vary slightly between CRI implementations (containerd vs CRI-O); verify exact syntax against the runtime actually in use.