PE-CRI
crictl
CLI para cualquier runtime compatible con CRI, usado para inspeccionar y depurar pods y contenedores a nivel de nodo Kubernetes.
Sitio oficialVolver al catálogo
RESUMEN
crictl (github.com/kubernetes-sigs/cri-tools) es el CLI oficial para la Container Runtime Interface (CRI), la API que usa Kubernetes para hablar con el runtime de contenedores que en realidad corre en un nodo — containerd, CRI-O u otra implementación de CRI. Como habla la API de CRI en vez de una específica de runtime, los mismos comandos funcionan sin importar qué motor está instalado, lo cual lo convierte en la herramienta de referencia para post-explotación en un worker node de Kubernetes cuando aún no sabes (o no quieres asumir) qué hay debajo.
Se parece lo suficiente a `docker` y `kubectl` como para ser usable de inmediato — `crictl pods`, `crictl ps`, `crictl inspect`, `crictl logs` — y expone detalles, como el digest exacto de imagen que corre un pod o rutas del host montadas, que a veces quedan ocultos una capa más arriba, en la propia API de Kubernetes.
CASOS DE USO
Casos de uso en un engagement
- 01
Enumerar pods y contenedores directamente en un nodo Kubernetes comprometido, sin importar el runtime subyacente.
- 02
Inspeccionar montajes, variables de entorno y digests de imagen que quizá no sean visibles solo con `kubectl`.
- 03
Extraer logs de un contenedor a nivel de nodo cuando el acceso al API server no está disponible o está restringido.
- 04
Verificar de forma cruzada el estado de contenedores a nivel de nodo contra lo que reporta el control plane de Kubernetes.
PRIMEROS PASOS
Tras llegar a un worker node de Kubernetes, para enumerar pods/contenedores a nivel de CRI sin importar qué runtime (containerd, CRI-O) hay debajo.
- Confirma que el acceso a nivel de nodo y cualquier inspección/escape de contenedores está explícitamente dentro del alcance del engagement.
- Verifica que crictl esté disponible (viene por defecto en muchas imágenes de nodo Kubernetes) o instálalo acorde a la versión CRI del clúster.
- Apúntalo al socket CRI del nodo, ej. `--runtime-endpoint unix:///run/containerd/containerd.sock`, si no está ya configurado.
- Enumera con `crictl pods` y `crictl ps -a`, luego usa `crictl inspect` sobre un contenedor de interés.
sudo crictl --runtime-endpoint unix:///run/containerd/containerd.sock ps -aANTES DE USARLA
Qué revisar antes de lanzarla
El acceso a CRI a nivel de nodo suele exponer todos los pods programados en ese nodo, incluidas cargas de otros equipos o clientes — trata los hallazgos según las reglas de manejo de datos del engagement.
Usar crictl para modificar o detener contenedores afecta cargas de trabajo reales en ese nodo — trátalo como una acción a nivel de host que requiere la misma autorización que cualquier otra herramienta de nodo.
El comportamiento y las flags pueden variar ligeramente entre implementaciones de CRI (containerd vs CRI-O); verifica la sintaxis exacta contra el runtime realmente en uso.