Networkpolicy on lo0 — Blog Técnico

Hardening y secretos del stack LLM soberano: defensa en profundidad

Thu, 11 Jun 2026 11:00:00 +0000

Parte de la serie operativa sobre exprimir un clúster LLM on-premise genérico 4×H100 SXM 80GB. Las piezas hermanas: la ingesta documental de PDF a chunk indexado que llena la base vectorial, el servicio de embeddings y rerankers con TEI en producción que la alimenta, y —la más directamente acoplada a este post— el GitOps del stack de inferencia con Flux, porque GitOps y secretos comparten un problema huevo-gallina que aquí resolvemos. El ensamblado completo de todo esto en un asistente conversacional (LibreChat + LiteLLM + RAG) lo cubre otro post de la serie, todavía en borrador.

TL;DR

Un stack de inferencia LLM soberano son, como mínimo, seis servicios: un gateway (LiteLLM o equivalente), un motor de inferencia (vLLM), un servicio de embeddings/rerankers (TEI), una base vectorial, una base de estado (conversaciones, usuarios) y un front (LibreChat). Seis servicios son seis superficies de ataque, y el asistente “funciona” en cuanto el gateway devuelve tokens — mucho antes de estar endurecido. Este post recorre la defensa en profundidad capa por capa:

Secretos: nunca en claro en git. sealed-secrets (cifrado asimétrico, controlador en el clúster) vs SOPS/age (cifrado de fichero, simple, GitOps puro) vs External Secrets Operator + Vault (secretos dinámicos, rotación nativa). El problema huevo-gallina del GitOps.
Red: NetworkPolicy default-deny + allow explícito; L3/L4 con la NetworkPolicy estándar, L7 y egress por DNS con Cilium (eBPF); control de egress para que el dato no salga del perímetro; mTLS interno.
Pod security: runAsNonRoot, readOnlyRootFilesystem, drop de capabilities, seccomp RuntimeDefault, Pod Security Standards restricted, nada privilegiado.
Cadena de suministro: pin por digest, escaneo con Trivy, firma con cosign, admission control que rechaza lo no firmado.
AuthN/Z: claves virtuales de LiteLLM, OIDC/LDAP en el front, RBAC de Kubernetes con mínimo privilegio.
Runtime: detección y, opcionalmente, enforcement con Tetragon.
Dato en reposo: cifrado de almacenamiento, credenciales de la base vectorial y de la base de estado.

La tesis: el hardening reduce el radio de impacto, no lo elimina. Por eso se prioriza por impacto, y el primer trabajo en un 4×H100 es el par gateway↔vector store y el egress-deny.

La analogía: el despacho soberano

Imagina un despacho que custodia documentación sensible — el corpus que alimenta el RAG, las conversaciones de los usuarios, las credenciales del motor. No basta con que la puerta de la calle cierre. La seguridad de verdad es defensa en profundidad: varias capas, cada una asumiendo que la anterior puede fallar.

El mapeo es directo:

El perímetro del edificio es el control de egress: que un secreto filtrado o un proceso comprometido no pueda exfiltrar el corpus a un servidor externo. Es la capa más infravalorada y la primera que pongo en un despliegue soberano.
El control de accesos en cada puerta interior es la NetworkPolicy default-deny: el front no habla con la base vectorial directamente porque no tiene por qué; solo los pares estrictamente necesarios están abiertos.
Los tabiques cortafuegos son el aislamiento de pod (restricted) y los namespaces: si un servicio arde, el fuego no salta al de al lado.
El portero que verifica credenciales es el admission control que comprueba la firma cosign de cada imagen antes de dejarla entrar al clúster.
Las cámaras son Tetragon/Falco: registran qué hizo cada proceso y detectan (o matan) lo anómalo.
La caja fuerte con llave rotada son los secretos: cifrados en reposo, fuera de git, y con rotación para que una llave robada caduque.

Ninguna capa es suficiente sola. El edificio es seguro porque atravesarlas todas es caro.

Capa 1 — Secretos: el problema huevo-gallina del GitOps

El stack se despliega por GitOps: la pieza hermana de Flux reconcilia el estado declarado en git contra el clúster. Eso es excelente para los manifiestos — pero hay un problema fundacional: el motor de inferencia necesita el token de Hugging Face para descargar el modelo, la base de estado necesita su contraseña, el gateway necesita su clave maestra. Esos secretos no pueden ir en claro en git. Cualquiera con acceso de lectura al repo —y en una organización con read generoso eso es mucha gente, más todo backup del repo, más todo fork— los leería.

El huevo y la gallina: GitOps quiere que todo el estado esté en git, pero los secretos no pueden estar en git en claro. La solución, en sus tres familias:

Familia A — sealed-secrets (cifrado asimétrico, controlador en el clúster)

Bitnami Sealed Secrets es un controlador que corre en el clúster más una CLI cliente, kubeseal. Usa criptografía asimétrica: hay un par de claves. La pública la tienen los desarrolladores y sirve para cifrar; la privada vive solo en el controlador del clúster y sirve para descifrar. El flujo:

El desarrollador toma un Secret normal y lo cifra con kubeseal, que obtiene la clave pública del controlador. Resultado: un recurso SealedSecret.
Ese SealedSecret sí se commitea a git en claro — está cifrado, no es legible.
El controlador en el clúster lo detecta, lo descifra con su clave privada y crea el Secret de Kubernetes real en el namespace destino.

La propiedad clave: como la clave privada nunca sale del clúster, ni el desarrollador ni nadie con acceso a git puede descifrar. Y el cifrado incluye el nombre del namespace: un SealedSecret sellado para inferencia no se puede mover a front y descifrarlo allí — se comporta como si cada namespace tuviera su propia llave. El controlador gestiona también la rotación de las claves de sellado, etiquetándolas como active o compromised.

Ventaja: encaja perfecto en GitOps puro, el secreto cifrado vive con el resto del estado. Limitación: el secreto, ya descifrado, acaba siendo un Secret de Kubernetes normal — está en etcd, y hay que cifrar etcd aparte (lo veremos en la capa 7).

Familia B — SOPS + age (cifrado de fichero, simple)

SOPS cifra el fichero YAML/JSON entero (o solo sus valores) y lo deja en git cifrado, descifrándolo solo en el momento del despliegue. Soporta KMS de nube (AWS/GCP/Azure), PGP y —lo relevante para soberanía on-premise— age, un esquema de cifrado offline simple sin servidor. El operador de GitOps (Flux trae integración nativa de SOPS) descifra al reconciliar usando la clave age guardada en el clúster.

Ventaja: simple, scriptable, sin servidor que mantener; el peso operativo recae en custodiar la clave age. Es la recomendación habitual para equipos pequeños o para arrancar. Limitación: la rotación es manual (re-cifrar todo con la nueva clave) y no hay secretos dinámicos.

Familia C — External Secrets Operator + Vault (secretos dinámicos, rotación nativa)

El External Secrets Operator (ESO) no guarda secretos en git en absoluto. En git solo va un ExternalSecret: una referencia que dice “el campo password viene del path secret/data/vectordb de tal SecretStore”. El operador lee de un almacén externo —típicamente HashiCorp Vault— y sincroniza el Secret de Kubernetes. Vault guarda los secretos en su propio backend cifrado y los sirve por API autenticada, de modo que nunca residen en git y, con sus motores dinámicos, puede emitir credenciales de base de datos de vida corta que caducan solas.

Ventaja: rotación nativa, secretos dinámicos, auditoría centralizada, un único punto de gobierno. Limitación: hay que operar Vault (sellado/desellado, alta disponibilidad, política de acceso), lo que es trabajo real.

Cómo elegir, y la rotación

Criterio	sealed-secrets	SOPS + age	ESO + Vault
Secreto en git	cifrado	cifrado	solo referencia
Servidor extra	controlador ligero	ninguno	Vault (pesado)
Rotación	claves de sellado auto	manual (re-cifrar)	nativa / dinámica
Secretos dinámicos (vida corta)	no	no	sí
Encaje GitOps puro	excelente	excelente	bueno (referencias)
Curva operativa	baja	muy baja	alta

Para un 4×H100 soberano arrancando, SOPS/age o sealed-secrets cubren el 90% con coste mínimo. Cuando el sistema crece y aparecen requisitos de rotación frecuente y auditoría —típico en escenarios ENS Categoría Alta— se migra a ESO + Vault. La regla de la rotación: un secreto que nunca rota es un secreto que, una vez filtrado, está filtrado para siempre. La rotación no impide la filtración; acota su ventana de validez. Volveremos a ello al hablar de radio de impacto.

Capa 2 — Red: default-deny, egress y la matemática de la superficie

La matemática de los pares de comunicación

Sin política de red, en Kubernetes todos los pods pueden hablar con todos los pods. Esa es la postura por defecto, y es la peor para un sistema soberano. Con $N$ servicios, el número de pares ordenados de comunicación posibles (quién-puede-llamar-a-quién) es:

$$P_{\text{abierto}} = N \cdot (N-1) \approx N^2$$

Con nuestros $N = 8$ componentes (gateway, vLLM, TEI, base vectorial, base de estado, front, además del controlador de secretos y el de observabilidad), eso son $8 \cdot 7 = 56$ pares dirigidos posibles. Cincuenta y seis caminos por los que un servicio comprometido podría pivotar lateralmente.

Ahora aplicamos NetworkPolicy default-deny: nada habla con nada salvo lo explícitamente permitido. La whitelist real de un stack LLM es pequeña. Los pares estrictamente necesarios:

front → gateway
gateway → vLLM
gateway → TEI
gateway → base vectorial
gateway → base de estado
front → base de estado (sesiones/usuarios)

Eso son $E = 6$ aristas. La superficie de comunicación cae de $56$ a $6$:

$$\frac{E}{P_{\text{abierto}}} = \frac{6}{56} \approx 0{,}107$$

Casi un 89% de los caminos posibles quedan cerrados. El front ya no puede tocar vLLM ni TEI ni la base vectorial directamente; si alguien compromete el front, no tiene ruta de red hacia el corpus. Esto es la diferencia entre $\sim N^2$ y una whitelist $E \ll N^2$.

L3/L4 estándar, L7 y egress con Cilium

La NetworkPolicy nativa de Kubernetes opera a L3/L4: selecciona pods por label y permite/deniega por puerto y protocolo. Sirve para el grueso de la whitelist. Pero tiene límites: no entiende DNS ni HTTP. Aquí entra Cilium, que aplica las políticas en el kernel vía eBPF y extiende con CiliumNetworkPolicy:

Egress por FQDN/DNS: en vez de fijar IPs (que cambian), permitir egress solo a huggingface.co para que vLLM descargue el modelo y bloquear el resto. Crítico para el control de egress.
L7: permitir solo ciertos métodos/paths HTTP entre gateway y un servicio interno.
Modos de enforcement: en modo por defecto, un endpoint sin política seleccionándolo tiene todo abierto; en modo always, todo está denegado hasta que una política lo abra explícitamente. Para un sistema soberano, always + default-deny es la postura objetivo.

El control de egress es la pieza soberana por excelencia. Que un servicio interno no pueda abrir conexiones a Internet salvo a un puñado de destinos explícitos significa que, aunque comprometan vLLM o el gateway, el corpus no puede salir del perímetro. El RAG es el activo de valor; el egress-deny es lo que impide que se fugue.

mTLS interno

La NetworkPolicy dice quién puede hablar con quién, pero no cifra ni autentica el tráfico este-oeste. Para eso, mTLS (TLS mutuo: cliente y servidor se autentican entre sí). Cilium ofrece autenticación mutua nativa; alternativas como Linkerd o Istio dan una malla de servicios completa. Para un stack de seis servicios, la malla completa de Istio suele ser sobreingeniería; la autenticación mutua de Cilium o Linkerd (más ligero) es proporcional. El efecto: un atacante en la red del clúster no puede suplantar al gateway ni espiar el tráfico interno en claro.

Capa 3 — Pod security: restricted, y nada privilegiado

Las Pod Security Standards definen tres perfiles: privileged (sin restricciones), baseline (lo mínimo razonable) y restricted (endurecido). El objetivo para todo el stack LLM es restricted, aplicado vía Pod Security Admission con label de namespace en modo enforce. El perfil restricted exige:

runAsNonRoot: true y runAsUser distinto de 0. Ningún contenedor corre como root.
readOnlyRootFilesystem: true. El sistema de ficheros raíz es de solo lectura; lo que necesite escribir va a un emptyDir o volumen explícito. Un atacante no puede dejar binarios persistentes en el contenedor.
drop: ["ALL"] de capabilities de Linux. Sin capacidades que no se necesiten.
seccomp RuntimeDefault, que aplica el perfil del runtime y bloquea las syscalls peligrosas.
allowPrivilegeEscalation: false, nada privileged, sin host namespaces.

El matiz con GPU: los pods que usan H100 cargan el device plugin de NVIDIA, lo que históricamente tentaba a relajar el securityContext. No hace falta correr el contenedor de inferencia como privilegiado para usar la GPU; el acceso al dispositivo se gestiona por el plugin, y el pod de vLLM puede y debe correr restricted. Esto es un tabique cortafuegos: si comprometen vLLM, el atacante tiene un proceso no-root, sin capabilities, con FS de solo lectura y syscalls recortadas — un punto de partida pésimo para escalar.

Capa 4 — Cadena de suministro de imágenes

La imagen de contenedor es código de terceros que corre con acceso a tus datos. Tres controles compuestos:

Pin por digest, no por tag. vllm/vllm-openai:latest es un blanco móvil; @sha256:... es inmutable. Fijar el digest garantiza que lo que se desplegó es exactamente lo auditado.
Escaneo con Trivy. Antes de promover una imagen, Trivy enumera sus CVEs y compone el SBOM (inventario de componentes). Falla el pipeline si hay vulnerabilidades críticas sin mitigar.
Firma con cosign y verificación en admission. El proyecto Sigstore (cosign para firmar, Fulcio como CA de certificados efímeros vía OIDC, Rekor como log de transparencia inmutable) permite firmar la imagen. Y el policy-controller de Sigstore —o Kyverno— es un admission controller que verifica la firma antes de admitir el pod: una imagen sin firma válida no entra al clúster.

Este es el portero de la analogía: comprueba la credencial (firma) de cada imagen en la puerta. Una imagen envenenada subida a un registro, o un tag secuestrado, se queda fuera porque no lleva firma del emisor de confianza.

Capa 5 — AuthN/Z: claves virtuales, OIDC y RBAC mínimo

Tres puntos de control de identidad, de fuera adentro:

Front (OIDC/LDAP). El usuario humano se autentica contra el proveedor de identidad corporativo. El front no inventa su propio sistema de usuarios; delega en OIDC. Esto da SSO, MFA y revocación centralizada.
Gateway (claves virtuales de LiteLLM). El gateway emite claves virtuales: cada equipo, aplicación o usuario tiene su clave con presupuesto, rate limit y modelos permitidos. La clave maestra del gateway —y las API keys reales hacia el motor— nunca las ve el cliente; solo manejan su clave virtual, revocable individualmente. Si se filtra una clave virtual, se revoca esa y solo esa.
Kubernetes RBAC con mínimo privilegio. Los ServiceAccount de cada servicio tienen los permisos justos. El pod de vLLM no necesita listar Secret de otros namespaces ni crear pods. RBAC restrictivo significa que un token de service account robado abre muy poco.

Capa 6 — Runtime: las cámaras con Tetragon

Las capas anteriores son preventivas. Falta la detección: ¿y si algo, pese a todo, se ejecuta donde no debe? Tetragon es seguridad observable y enforcement en runtime sobre eBPF, Kubernetes-aware. Hooka eventos del kernel —process_exec, tcp_connect, security_file_open— con sobrecarga típica por debajo del 1%, y puede pasar de observar (registrar el evento) a enforcement (matar el proceso o cortar la conexión en el kernel, Sigkill).

La regla operativa, que detallo en el runbook de bubblewrap + Tetragon: adopta primero, bloquea después. Primero se despliega en modo observación para levantar un baseline del comportamiento normal del stack —qué binarios ejecuta vLLM, a qué se conecta el gateway— sin falsos positivos. Solo después se promueven a enforcement las reglas claras: matar cualquier proceso que intente leer rutas de secretos, o cortar todo tcp_connect a destinos fuera de la whitelist de egress. Falco es la alternativa detection-only sobre eBPF; Tetragon añade enforcement. Estas cámaras producen, además, la evidencia de auditoría: qué ejecutó cada servicio y qué intento se bloqueó.

Capa 7 — Dato en reposo

Lo último que protegemos es el dato parado:

Cifrado del almacenamiento. Los volúmenes persistentes —donde viven la base vectorial y la base de estado— sobre cifrado de disco (LUKS/dm-crypt) o cifrado a nivel de Ceph. Un disco robado del CPD no revela el corpus.
Cifrado de etcd. Recuerda que los Secret de Kubernetes, una vez descifrados por sealed-secrets o ESO, son objetos normales en etcd. Hay que activar el encryption at rest de etcd, o el secreto está en claro en el plano de control.
Credenciales de las bases. La contraseña de la base vectorial y la de la base de estado son secretos de primera (capa 1), nunca embebidas en el manifiesto ni en variables de entorno en claro en git.

Tabla de exposición: servicio × puerto × ¿egress externo?

Esta tabla es el insumo para escribir las NetworkPolicy. La columna de egress es la que decide qué sale del perímetro.

Servicio	Puerto interno	Llamantes permitidos	¿Egress externo?
front	3080	(ingress humano vía OIDC)	No
gateway (LiteLLM)	4000	front	No
vLLM	8000	gateway	Solo `huggingface.co` para descarga inicial; cero en operación
TEI (embeddings/reranker)	8080	gateway	Solo descarga del modelo; cero en operación
base vectorial	6333	gateway	No
base de estado	5432	gateway, front	No
controlador de secretos	—	(plano de control)	No
observabilidad	9090	scraping interno	No

La lectura: ningún servicio necesita egress externo en operación normal. vLLM y TEI lo necesitan una vez para bajar el modelo, y ese permiso puede ser temporal o restringido por FQDN a huggingface.co. Todo lo demás es egress-deny total. Si un servicio empieza a intentar conexiones de salida que esta tabla no contempla, Tetragon lo registra y, en enforcement, lo corta.

Radio de impacto: un secreto filtrado, con y sin defensa

El radio de impacto (blast radius) mide cuánto daño hace un compromiso. Modelémoslo para el peor caso realista: se filtra la credencial de la base de estado.

Sin hardening (red plana, secreto sin rotar, sin egress-deny, sin detección):

El secreto da acceso a la base de estado desde cualquier pod (red plana → 56 pares abiertos).
El secreto no rota → es válido indefinidamente; la ventana de explotación es $\infty$ hasta que alguien lo note.
Sin egress-deny, el atacante vuelca la base entera a un servidor externo.
Sin Tetragon, nadie se entera hasta el incidente público.
Radio de impacto: toda la base de estado, exfiltrada, sin detección, por tiempo indefinido.

Con hardening (default-deny, ESO + Vault con credenciales dinámicas, egress-deny, Tetragon en enforcement):

El secreto solo es usable desde el pod que tiene ruta de red a la base de estado (1-2 pares, no 56).
Con credenciales dinámicas de Vault, el secreto caduca —digamos en una ventana $T$ de horas—; pasado $T$, no vale nada.
El egress-deny impide el volcado a Internet: el atacante puede leer, pero no sacar.
Tetragon registra el acceso anómalo y, en enforcement, mata el proceso que intenta la conexión de salida.

La reducción cualitativa es enorme, pero seamos cuantitativos con la ventana. Si un secreto estático vale para siempre y uno rotado con periodo $T$ vale como mucho $T$, y los compromisos llegan a tasa $\lambda$, el número esperado de secretos vivos y explotables en un instante dado pasa de crecer sin techo a quedar acotado por $\lambda \cdot T$. Con rotación cada 24 h ($T = 1$ día) frente a “nunca”, la ventana de un secreto concreto cae de meses a un día: una reducción de uno a dos órdenes de magnitud en la exposición temporal. Combinado con la reducción de pares de red ($56 \to \sim 2$, factor $\sim 28\times$) y el egress-deny (de exfiltración posible a imposible por la ruta directa), el radio de impacto se reduce drásticamente.

Pero seamos honestos: no llega a cero. El atacante con la credencial puede leer la base de estado durante la ventana $T$ desde el pod comprometido. El hardening convirtió “catástrofe indefinida y silenciosa” en “incidente acotado, detectado y sin exfiltración por la vía directa”. Eso es exactamente lo que la defensa en profundidad promete: no la invulnerabilidad, sino que el coste de un compromiso completo sea alto y su radio, pequeño.

Ángulo ENS / NIS2

Estas capas no son higiene voluntaria: materializan controles concretos. El mapeo lo desarrolla en detalle el post de controles técnicos ENS × ISO 42001 × EU AI Act; aquí, el resumen accionable:

Capa de hardening	Medida ENS (RD 311/2022)	Vínculo NIS2 / marco
Secretos cifrados + rotación	`op.exp.11` (claves criptográficas), `mp.info.3` (cifrado)	Gestión de credenciales; en Cat. Alta, HSM
NetworkPolicy default-deny + segmentación	`mp.com.1` (perímetro), `mp.com.4` (separación de flujos)	NIS2 art. 21: medidas de seguridad de red
Control de egress	`mp.com.1` + `op.mon.1`	Prevención de exfiltración
mTLS interno	`mp.com.2-3` (confidencialidad/integridad en tránsito)	TLS obligatorio
Pod Security restricted	`op.exp.2` (config endurecida)	Hardening de configuración (CIS)
Trivy + cosign + admission	`op.exp.6` (código dañino), `op.ext.3` (cadena de suministro)	NIS2 supply chain
OIDC + claves virtuales + RBAC	`op.acc.1-2-5` (identificación, acceso, autenticación)	MFA en Cat. Alta
Tetragon runtime	`op.mon.1` (detección de intrusión)	Monitorización y respuesta
Cifrado en reposo + etcd	`mp.info.3` (cifrado), `mp.si` (soportes)	Dato en reposo

La nota honesta para auditoría: el hardening reduce el riesgo, no lo elimina, y la madurez se demuestra priorizando por impacto. Un auditor competente no quiere ver las nueve capas a medias; quiere ver que el egress-deny del activo crítico (el corpus) y la gestión de secretos están sólidos antes que el mTLS perfecto entre servicios de baja sensibilidad. Para el contexto de gestión y gobernanza, ver también ISO/IEC 42001 como AIMS y el mapeo del EU AI Act sobre la arquitectura.

Aplicado al clúster genérico 4×H100

En un despliegue real sobre 4×H100 SXM 80GB, no se endurecen las nueve capas a la vez. El orden, priorizado por impacto:

Egress-deny sobre vLLM, TEI y la base vectorial, primero. Es la barrera que impide que el corpus salga del perímetro, y se pone en cuanto los servicios arrancan. Permite egress por FQDN a huggingface.co solo durante la descarga inicial del modelo; después, cero. Es la capa de mayor retorno por hora invertida.
Secretos del motor de inferencia y de las bases, fuera de git. El token de Hugging Face que usa vLLM para descargar el modelo, las contraseñas de la base vectorial y de la base de estado, la clave maestra del gateway: a sealed-secrets o, si ya hay requisito de rotación, a ESO + Vault. Nunca en el values.yaml en claro.
NetworkPolicy default-deny + la whitelist de 6 aristas. El gateway y la base vectorial son los servicios más expuestos —el gateway porque recibe todo el tráfico, la base vectorial porque custodia el RAG embebido—. Cerrar todo lo que no sea la whitelist recorta el pivoteo lateral del $\sim N^2$ a las 6 aristas reales.
Pod Security restricted en el namespace de inferencia, incluido el pod de vLLM con GPU (no necesita privilegios para usar la H100).
cosign + admission para que solo entren imágenes firmadas; Trivy en el pipeline de GitOps de Flux.
Tetragon en observación, baseline, y luego enforcement sobre el egress de los pods sensibles.
Cifrado en reposo de los volúmenes de las bases y de etcd.

El gateway y la base vectorial son los dos que endurezco primero dentro de la whitelist: el gateway por ser la cara expuesta, la base vectorial por contener el activo que el egress-deny protege. El resto se construye encima, capa a capa, asumiendo siempre que la anterior puede fallar.

Lo que el hardening NO resuelve

Para cerrar con honestidad, lo que estas capas no cubren y necesita otras piezas:

Ataques a nivel de prompt (jailbreak, inyección indirecta vía el corpus RAG): eso es trabajo de guardrails y LLM Guard, no de NetworkPolicy.
Agentes con permisos legítimos que hacen algo dañino: el aislamiento de runtime del post de aislar agentes acota qué puede tocar un agente, pero un permiso concedido es un permiso usable.
El factor humano: un secreto bien gestionado pero compartido por Slack sigue filtrado. La rotación acota la ventana, no elimina el error.
Vulnerabilidades zero-day en los propios componentes: Trivy detecta lo conocido; lo desconocido pasa hasta que se publica el CVE.

El hardening es un multiplicador del coste de atacar, no un muro infranqueable. Su valor está en hacer que un compromiso individual quede acotado, detectado y sin salida — y eso, para un sistema soberano que custodia datos sensibles, es exactamente el objetivo.

Ver también

GitOps del stack de inferencia con Flux — la pieza hermana: GitOps reconcilia el estado, y comparte con este post el problema huevo-gallina de los secretos.
Controles técnicos: ENS × ISO 42001 × EU AI Act — el mapeo detallado de cada capa de hardening a medida ENS, control 42001 y artículo del AI Act.
ISO/IEC 42001: el AIMS del LLM on-premise — el sistema de gestión que enmarca el hardening como control documentado.
EU AI Act: mapeo sobre la arquitectura LLM on-premise — los artículos de robustez y ciberseguridad (Art. 15) que estas capas satisfacen.
LLM Guard: fundamentos — la capa de seguridad a nivel de prompt/contenido que el hardening de infraestructura no cubre.
Guardrails y safety en LLMs — el WAF semántico complementario a la NetworkPolicy.
Aislar agentes de IA: del workstation al clúster — el modelo de amenaza del aislamiento de runtime.
Runbook: enjaular al agente de IA con bubblewrap y Tetragon — el procedimiento operativo de Tetragon (observar primero, bloquear después) referenciado en la capa 6.

Runbook: enjaular al agente de IA — bubblewrap en el cliente, Tetragon en el cluster

Tue, 09 Jun 2026 17:00:00 +0200

Compañero operativo de El contratista con la llave maestra. Aquel post explica el porqué y el dónde —el modelo de amenaza, las cinco familias de aislamiento, qué dominio usa cada una—; este es el cómo, con comandos. Si no lo has leído, léelo antes: aquí doy por sabido qué es el radio de explosión, por qué bwrap corre sin root y qué vigila Tetragon. El procedimiento va en dos tracks independientes —cliente y cluster— porque, como argumenta el post hermano, el control se extrapola pero la primitiva se reescribe.

TL;DR

Dos procedimientos reproducibles. Cliente (workstation): instala ai-jail (envuelve bubblewrap), genera el .ai-jail por proyecto, audita con --dry-run, fija las allowlists con --bootstrap, usa --lockdown para lo que no te fíes, y deja al agente sin permiso de git push. Cluster (RKE2 con Cilium + Tetragon): pon el baseline de pod (securityContext sin privilegios, seccomp: RuntimeDefault, NetworkPolicy default-deny), mete el pod del agente no confiable en una microVM con runtimeClassName: kata, y despliega las TracingPolicy de Tetragon en dos fases —observar con action: Post para levantar el baseline, luego promover a action: Sigkill sobre tcp_connect (egress) y security_file_open (rutas de secretos)—. La regla de oro de la fase Tetragon: adopta primero, bloquea después; nunca metas un Sigkill en producción sin haber visto antes los eventos en modo observación.

El flujo de los dos tracks

Track A — Cliente (workstation del desarrollador)

A0 — Instalar ai-jail y bubblewrap

ai-jail envuelve el sandbox; en Linux necesita bubblewrap aparte, en macOS no necesita dependencia extra.

# ai-jail (macOS y Linux)
brew tap akitaonrails/tap && brew install ai-jail
# o, con cargo:
cargo install ai-jail
# o, con mise:
mise use -g ubi:akitaonrails/ai-jail

# bubblewrap en Linux (elige tu distro)
sudo pacman -S bubblewrap # Arch
sudo apt install bubblewrap # Debian / Ubuntu
sudo dnf install bubblewrap # Fedora

Comprueba que el binario está y que bwrap corre sin root (no debe pedir sudo):

ai-jail --version
bwrap --ro-bind / / --unshare-all echo "bwrap ok sin root"

Si bwrap falla pidiendo privilegios, tu kernel tiene los unprivileged user namespaces deshabilitados; habilítalos (sysctl kernel.unprivileged_userns_clone=1 en Debian/Ubuntu antiguos) antes de seguir.

A1 — El fichero .ai-jail por proyecto

En el primer arranque dentro del proyecto, ai-jail crea un .ai-jail (TOML) commiteable al repo: cualquier compañero que clone hereda la misma política.

cd ~/Projects/mi-app
ai-jail claude # crea .ai-jail y lanza Claude Code dentro del sandbox

El fichero generado:

# .ai-jail — configuración del sandbox (commitéalo al repo)
command = ["claude"]
rw_maps = [] # directorios extra con escritura
ro_maps = [] # directorios extra de solo lectura

Antes de confiar en el sandbox, audítalo. --dry-run --verbose imprime cada punto de montaje, cada flag de aislamiento y el comando bwrap completo, sin ejecutar nada:

ai-jail --dry-run --verbose claude

Lee la salida y confirma tres cosas: que $HOME se monta como tmpfs (no el real), que ~/.ssh, ~/.aws y ~/.gnupg no aparecen entre los montajes, y que el único directorio con escritura es el del proyecto. Si necesitas un directorio extra:

ai-jail --rw-map ~/Projects/shared-lib claude # extra con escritura
ai-jail --map /opt/datasets claude # extra de solo lectura

Otros agentes, mismo binario:

ai-jail codex
ai-jail opencode
ai-jail bash # shell pelado para depurar el sandbox
ai-jail -- python script.py # cualquier comando

A2 — Las allowlists de permisos con –bootstrap

--bootstrap genera las configuraciones de permisos de cada agente, con allow/deny/ask sensatos, y hace backup antes de sobrescribir:

ai-jail --bootstrap

Lo que produce, en resumen:

Agente	Fichero	Política base
Claude Code	`~/.claude/settings.json`	allow: `git status/diff/log`, `ls`, `grep`, `cargo`, `npm`, `python`, `docker compose` · ask: `git push`, `rm`, `docker run` · deny: `rm -rf`, `sudo`, `chmod 777`, `git push --force`
Codex	`~/.codex/config.toml`	`approval_policy = "on-request"`
OpenCode	`~/.config/opencode/opencode.json`	permisos de `bash`, `edit`, `write`

La clave operativa: git push está en ask, no en allow, y git push --force en deny. El agente puede commitear, ramear y rebasar localmente cuanto quiera; nada de eso toca el remoto. (Si usas el /sandbox de Claude Code, fija además "allowUnsandboxedCommands": false para cerrar el escape hatch dangerouslyDisableSandbox, que de fábrica es opt-out.)

A3 — Lockdown para lo que no te fíes

Para auditar código de terceros o correr un agente sobre un proyecto que no conoces, --lockdown va más allá: proyecto montado en read-only, GPU/Docker/display deshabilitados, --rw-map/--map ignorados, $HOME tmpfs puro sin dotfiles del host, red cortada con --unshare-net y environment limpiado con --clearenv.

ai-jail --lockdown bash

Es el sandbox más restrictivo posible sin llegar a una VM. Úsalo como defecto mental para todo lo que no sea tu propio código en tu propia máquina.

A4 — La red de seguridad: git sin push

No es un flag, es una propiedad del entorno que cambia el cálculo de riesgo. Si el proyecto está en git con remoto, y el agente no tiene permiso de push, el peor caso —que corrompa cada fichero del proyecto— se revierte con:

git checkout . # vuelve al último commit
# y si tocó .git (improbable): borra el dir y re-clona

El remoto nunca se tocó. Sandbox para el filesystem + git para el código + push manual es ya un nivel razonable para uso diario: ai-jail protege tus datos y el sistema, git protege el código, y la decisión de publicar sigue siendo tuya.

Track B — Cluster (RKE2 con Cilium + Tetragon)

El agente no confiable —o la inferencia que ejecuta código generado— corre como pod. El mismo principio del cliente, otras primitivas. Asumimos un cluster genérico RKE2 con Cilium como CNI y Tetragon ya desplegado (el DaemonSet del agente eBPF en cada nodo).

B0 — El baseline del pod

Antes de cualquier eBPF, lo de serie. securityContext sin privilegios, raíz read-only, seccomp por defecto:

apiVersion: v1
kind: Pod
metadata:
 name: ai-agent
 namespace: agentes
 labels:
 app: ai-agent
spec:
 securityContext:
 runAsNonRoot: true
 runAsUser: 10001
 seccompProfile:
 type: RuntimeDefault
 containers:
 - name: agent
 image: registry.interno/ai-agent:pinned
 securityContext:
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 capabilities:
 drop: ["ALL"]
 volumeMounts:
 - { name: work, mountPath: /work }  # único escribible
 volumes:
 - name: work
 emptyDir: {}

Y el corte de egress por defecto —el gemelo cluster del --unshare-net—. NetworkPolicy default-deny de salida en el namespace, abriendo solo DNS y lo imprescindible:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: default-deny-egress
 namespace: agentes
spec:
 podSelector: {}
 policyTypes: ["Egress"]
 egress:
 - to:
 - namespaceSelector:
 matchLabels: { kubernetes.io/metadata.name: kube-system }
 ports:
 - { protocol: UDP, port: 53 }
 - { protocol: TCP, port: 53 }

B1 — RuntimeClass Kata: el pod no confiable en su propia microVM

Para código realmente no confiable, sácalo del kernel compartido. Con Kata desplegado existe un RuntimeClass:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
 name: kata
handler: kata

Y el pod lo pide con una línea —runtimeClassName: kata—, ejecutándose en su propia microVM con kernel dedicado en lugar de compartir el del nodo:

spec:
 runtimeClassName: kata  # ← el pod corre en una microVM, no en el kernel del nodo
 # ...resto igual que B0

Es el gemelo cluster del aislamiento por construcción: un exploit de kernel dentro del pod no alcanza al nodo.

B2 — Tetragon, fase observación (Post)

Ahora la capa que distingue una plataforma con visibilidad de runtime. Primero observar, nunca matar de entrada. Una TracingPolicyNamespaced —scoped al namespace y a la etiqueta del agente— que reporta (no mata) tres cosas: ejecuciones de proceso, conexiones de red y aperturas de rutas sensibles. action: Post solo emite el evento.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
 name: agente-observa
 namespace: agentes
spec:
 podSelector:
 matchLabels:
 app: ai-agent
 kprobes:
 # --- conexiones salientes ---
 - call: "tcp_connect"
 syscall: false
 args:
 - index: 0
 type: "sock"
 selectors:
 - matchActions:
 - action: Post
 # --- aperturas de ficheros sensibles ---
 - call: "security_file_open"
 syscall: false
 args:
 - index: 0
 type: "file"
 selectors:
 - matchArgs:
 - index: 0
 operator: "Prefix"
 values:
 - "/var/run/secrets"
 - "/work/.git/config"
 matchActions:
 - action: Post

(Las ejecuciones de proceso no necesitan kprobe: Tetragon emite process_exec/process_exit de forma nativa.) Despliega y observa los eventos en vivo desde el pod de Tetragon del nodo:

kubectl apply -f agente-observa.yaml
# eventos legibles, filtrando por el namespace:
kubectl exec -n kube-system ds/tetragon -c tetragon -- \
 tetra getevents -o compact --namespace agentes

Deja esto rodando una jornada típica del agente. Apunta a qué destinos conecta de verdad (tu registry interno, tu mirror de HF, tu endpoint de vLLM) y qué rutas abre. Eso es tu baseline: la lista de lo legítimo. Sin este paso, un Sigkill mata trabajo bueno y te genera un incidente de disponibilidad —justo lo que el ENS te pide evitar—.

B3 — Tetragon, fase enforcement (Sigkill)

Con el baseline en la mano, promueve a bloqueo. Dos reglas. La primera: mata cualquier conexión cuyo destino no esté en la allowlist —NotDAddr invierte el match: dispara para todo lo que no sea esas redes—. La segunda: mata cualquier intento de abrir una ruta de secretos.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
 name: agente-enforce
 namespace: agentes
spec:
 podSelector:
 matchLabels:
 app: ai-agent
 kprobes:
 # --- egress: mata todo lo que NO sea la allowlist ---
 - call: "tcp_connect"
 syscall: false
 args:
 - index: 0
 type: "sock"
 selectors:
 - matchArgs:
 - index: 0
 operator: "NotDAddr"
 values:
 - "127.0.0.1"
 - "10.0.0.0/8" # red interna del cluster
 - "172.16.10.20" # registry interno (ejemplo)
 matchActions:
 - action: Sigkill
 # --- lectura de secretos: mata el proceso ---
 - call: "security_file_open"
 syscall: false
 args:
 - index: 0
 type: "file"
 selectors:
 - matchArgs:
 - index: 0
 operator: "Prefix"
 values:
 - "/var/run/secrets/kubernetes.io/serviceaccount/token"
 - "/work/.ssh"
 matchActions:
 - action: Sigkill

kubectl apply -f agente-enforce.yaml

Ahora el agente puede hacer lo que quiera dentro del pod, pero en el instante en que intenta conectar a un destino no permitido o leer el token de la service account, Tetragon lo mata en el kernel —antes de que el paquete salga o el read devuelva bytes—. Es el gemelo cluster de la blocklist de curl y del ~/.ssh no montado, pero aplicado en runtime y sobre cualquier binario, no solo los que conoces.

Aviso operativo. El enforcement con Sigkill requiere kernel reciente con soporte de la acción en eBPF (5.10+ es seguro). Despliega agente-enforce primero en un namespace de pruebas, y mantén agente-observa activo en paralelo: si el bloqueo dispara, el evento Post te dice exactamente qué lo provocó. Adopta primero, bloquea después.

La tabla de equivalencias cliente ↔ cluster

El mismo vector, las dos primitivas. Esto es “extrapolar la tecnología” hecho explícito:

Vector de amenaza	Cliente (workstation)	Cluster (RKE2)
`$HOME` / raíz escribible	`$HOME` como tmpfs efímero (`bwrap`)	`readOnlyRootFilesystem: true` + `emptyDir`
Egress arbitrario	blocklist `curl`/`wget` · `--unshare-net`	NetworkPolicy default-deny + Tetragon `NotDAddr`→`Sigkill`
Lectura de secretos	`~/.ssh`/`~/.aws`/`~/.gnupg` no montados	secretos fuera del pod + Tetragon `security_file_open`→`Sigkill`
Escape del kernel	Landlock (2ª barrera VFS)	`runtimeClassName: kata` (microVM, kernel propio)
Sin escape hatch	proceso dentro de `bwrap`, sin salida	sin `privileged`, `drop ALL`, `allowPrivilegeEscalation:false`
Daño al código	git remoto sin `push` → `git checkout .`	GitOps + revisión de PR, el agente no aplica a `main`
Visibilidad	`--dry-run --verbose` (estático, pre-run)	Tetragon `tetra getevents` (dinámico, en runtime)

Checklist de gotchas

No metas un Sigkill sin pasar por Post. El baseline de observación no es opcional: es lo que separa “bloquear un C2” de “tirar tu propio job de fine-tuning”.
El .ai-jail se commitea; los secretos no. El TOML es política, no credenciales. Verifica que no metes rutas con datos sensibles en rw_maps.
readOnlyRootFilesystem rompe apps que escriben en /tmp. Monta un emptyDir en /tmp además del de trabajo.
NetworkPolicy sin regla de DNS deja al pod ciego. Abre el puerto 53 a kube-system o nada resuelve.
Kata no es gratis. Añade latencia de arranque y no todo workload con dispositivos especiales (GPU passthrough) encaja; resérvalo para lo no confiable, no para todo.
El /sandbox de Claude Code no cubre MCP ni hooks salvo que actives sandbox-runtime. Si tu agente usa servidores MCP, asume que corren con permisos completos hasta que lo hagas.
NotDAddr con IPs literales envejece mal. Documenta la allowlist y revísala cuando cambie el registry o el endpoint de inferencia; considera CIDRs internos estables en vez de IPs sueltas.

Ver también

Hardening y secretos del stack LLM soberano: defensa en profundidad — el hardening del cluster completo más allá del aislamiento del agente.
El contratista con la llave maestra: aislar agentes de IA del workstation al cluster — el panorama que este runbook ejecuta: modelo de amenaza, las cinco familias de aislamiento y por qué cliente y cluster usan primitivas distintas.
La puerta de la cocina que el maître no miró: Cilium eBPF y DRANET — la capa eBPF de Cilium sobre la que Tetragon engancha sus kprobes; el datapath que ya tienes en el cluster.
Controles técnicos: ENS × ISO 42001 × EU AI Act — los eventos de Tetragon como evidencia técnica de op.mon/op.exp; el enforcement como medida de protección.
Guardrails y safety en LLM — la mitigación en el plano del contenido; este runbook, la del plano de la ejecución.
Siete fases de despliegue de una plataforma LLM on-premise — dónde encaja el endurecimiento de runtime en la secuencia de despliegue (F4 identidad/políticas, F5 plataforma).

Referencias

ai-jail (Fabio Akita), GPL-3.0: https://github.com/akitaonrails/ai-jail
bubblewrap: https://github.com/containers/bubblewrap
Landlock LSM: https://landlock.io
Tetragon — TracingPolicy: https://tetragon.io/docs/concepts/tracing-policy/
Tetragon — enforcement (Sigkill/Override): https://tetragon.io/docs/concepts/enforcement/
Kata Containers — Kubernetes RuntimeClass: https://katacontainers.io
Kubernetes — Pod Security & seccomp: https://kubernetes.io/docs/tutorials/security/seccomp/
Kubernetes — Network Policies: https://kubernetes.io/docs/concepts/services-networking/network-policies/
Cilium: https://cilium.io