Qué es Kloak y qué problema resuelve

Qué pasó: el lanzamiento y por qué importa

Contexto: el largo camino de los secretos en Kubernetes

Primera oleada: encriptación en reposo y RBAC

Segunda oleada: gestores externos y sidecars

Tercera oleada: SPIFFE y mTLS por identidad

Cómo funciona Kloak con eBPF

Arquitectura: control plane y data plane

Datos y cifras: por qué eBPF cambia la ecuación

Impacto y análisis para equipos en LATAM

Qué sigue para Kloak y para el ecosistema

Preguntas frecuentes

¿Reemplaza Kloak a HashiCorp Vault?

¿Qué pasa si reinicio un pod o nodo?

¿Funciona en clusters managed como EKS, GKE y AKS?

¿Tiene impacto en el rendimiento de la aplicación?

¿Qué pasa si un atacante intenta cambiar la URL del request a su propio dominio?

¿Es viable para startups pequeñas o solo para empresas grandes?

Referencias La gestión de secretos en Kubernetes sigue siendo uno de los puntos más frágiles de cualquier stack cloud-native. Tokens de API, llaves de bases de datos, credenciales de Stripe o de OpenAI: cualquier proceso dentro de un pod que pueda leer una variable de entorno o un volumen montado, puede leer también esos secretos. Kloak propone un enfoque distinto basado en eBPF: que la aplicación nunca llegue a ver el secreto real, ni en RAM, ni en logs, ni accidentalmente impreso en un stack trace. El proyecto, publicado bajo licencia AGPL-3.0 y disponible en getkloak.io, intercepta el tráfico HTTPS saliente de cada pod desde el kernel y sustituye un identificador opaco por la credencial real justo antes de que el paquete cifrado abandone la máquina. Kloak ebpf es, en otras palabras, un proxy invisible que vive más cerca del hardware que del runtime de tu aplicación. Kloak se define a sí mismo como un Kubernetes eBPF HTTPS Interceptor. La idea es simple de explicar pero técnicamente delicada de implementar: en lugar de inyectar el secreto dentro del pod (vía Secret montado, variable de entorno, sidecar de Vault o CSI driver), Kloak deja que la aplicación use un placeholder ULID en su configuración. Cuando la aplicación arma un request HTTPS, el header sale del proceso con el placeholder. Y antes de ser cifrado y enviado por la red, un programa eBPF reemplaza ese placeholder por el secreto real. El resultado es contraintuitivo y poderoso al mismo tiempo. Si un atacante logra ejecución remota dentro del contenedor, puede listar variables de entorno, hacer dump de memoria, leer archivos, incluso colgarse de un debugger del proceso. Y aún así, no obtiene la credencial: solo el placeholder. Como dice la propia documentación: “Your applications never see the actual credentials, so a compromised process cannot leak what it never had.” 💭 Clave: Kloak invierte el modelo tradicional de inyección de secretos. En vez de empujar la credencial hacia adentro del pod, la mantiene fuera y la inserta en el último kilómetro, ya en el kernel, justo antes de cifrar el paquete TLS. Kloak opera en el plano de datos del kernel y resuelve los placeholders sin tocar el código de la aplicación. El proyecto se hizo público con un instalador Helm de tres líneas, un demo embebido y un mensaje claro para equipos de plataforma: agentless Kubernetes security. Sin sidecars que aumenten el footprint de cada pod. Sin SDKs que haya que importar en Python, Go o Node. Sin un CNI plugin propio que pelee con Cilium o Calico. Solo un controller que mira los Secrets etiquetados con getkloak.io/enabled=true y un programa eBPF que vive en el host. Para entender por qué kloak ebpf aparece en este momento hay que mirar lo que pasó en los últimos años. Vault de HashiCorp se volvió la opción enterprise pero con costo operacional alto. AWS Secrets Manager y GCP Secret Manager simplificaron el almacenamiento, pero el secreto sigue cayendo dentro del proceso al final del flujo. Sealed Secrets y External Secrets Operator resolvieron el problema del GitOps, pero no el del runtime. Y los incidentes de supply chain en npm, PyPI y Go durante 2025 y 2026 demostraron que la frontera más débil sigue siendo el código que se ejecuta dentro del pod. Kubernetes nació en 2014 con un modelo de Secrets que en la práctica son ConfigMaps con base64. La crítica está bien documentada: no están cifrados en reposo por defecto, son visibles para cualquier proceso del pod y se filtran fácil en logs cuando un desarrollador hace console.log(process.env). La industria respondió con tres oleadas de soluciones. Activar EncryptionConfiguration en etcd y endurecer RBAC para que solo ServiceAccounts específicos puedan leer Secrets. Necesario, pero insuficiente: el secreto sigue llegando descifrado al pod. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault con CSI driver, External Secrets Operator. El secreto vive fuera del cluster y se sincroniza dinámicamente. El problema de fondo persiste: una vez que la credencial entra al pod (como variable de entorno, archivo o respuesta HTTP de un sidecar), cualquier proceso del pod la puede leer. SPIFFE/SPIRE elimina los long-lived secrets entre servicios internos sustituyéndolos por identidades criptográficas de corta duración. Excelente para tráfico este-oeste, pero no resuelve credenciales hacia APIs externas como Stripe, OpenAI, Twilio o GitHub. Kloak ataca exactamente ese hueco: las credenciales hacia terceros que la aplicación necesita en runtime y que hoy llegan al pod en claro. El flujo de kloak ebpf tiene tres pasos. Primero, registrás el Secret en Kubernetes con un par de labels. El controller detecta el cambio, calcula un placeholder ULID único y mantiene el mapeo placeholder → secreto en su control plane. Segundo, en tu aplicación referenciás el placeholder en lugar del secreto real. La configuración nunca contiene la credencial: Tercero, cuando tu proceso arma el request HTTPS y lo manda al socket, un programa eBPF en tc (traffic control) intercepta el buffer del kernel, reconoce el patrón kloak:<ulid> en el header Authorization, y lo reemplaza por el valor real antes de que TLS haga el handshake. La aplicación nunca tuvo la credencial en su espacio de direcciones. ⚠️ Ojo: el reemplazo ocurre antes del cifrado TLS porque eBPF opera sobre el buffer en plaintext del kernel. Esto es por diseño: si el TLS ya hubiera cifrado, el placeholder sería irrecuperable. Kloak por lo tanto requiere que la TLS termination la maneje el kernel-side de la transformación. Kloak separa control y datos al estilo Kubernetes nativo. El controller corre como Deployment dentro del cluster, observa los Secrets etiquetados, gestiona los placeholders y los empuja al data plane. El data plane es un DaemonSet que carga los programas eBPF en cada nodo y maneja la traducción placeholder → secreto en kernel space. La instalación con Helm es directa y sirve para cualquier sistema operativo desde el que administres tu cluster: Arquitectura agentless: el data plane vive en el host, no en cada pod. El argumento de rendimiento de Kloak descansa en eBPF. La tecnología, originada en el kernel de Linux como evolución del filtro de paquetes BPF clásico, permite ejecutar programas verificados en kernel space sin necesidad de recompilar el kernel ni cargar módulos. Cilium, Pixie, Tetragon, Falco y muchos otros proyectos cloud-native ya demostraron que eBPF agrega overhead negligible para tareas de red. Para equipos de plataforma en América Latina, donde los presupuestos de seguridad suelen ser más ajustados que los de empresas en Estados Unidos o Europa, Kloak resuelve un dolor concreto: cumplir con auditorías de PCI-DSS, ISO 27001 o regulaciones locales como la Ley de Protección de Datos Personales en distintos países, sin contratar HashiCorp Enterprise ni montar una infraestructura de secrets management compleja. El modelo agentless tiene además una ventaja política dentro de las organizaciones. Adoptar un sidecar requiere convencer al equipo de aplicaciones de aceptar más overhead por pod, ajustar manifests, lidiar con order de inicio, etc. Kloak se instala una sola vez en el cluster y los equipos de aplicación solo cambian un valor en su config. El uso de control de hosts (getkloak.io/hosts) es uno de los detalles que merece atención. Define a qué dominios puede ir cada secreto. Si un atacante cambia la URL del request en runtime para apuntar a un dominio bajo su control, el placeholder no se traduce y el ataque falla. Es defense-in-depth real, no marketing. 💡 Tip: empezá adoptando Kloak para los secretos de mayor riesgo: claves de pago (Stripe, MercadoPago), credenciales de bases de datos hacia servicios gestionados, y tokens de proveedores de IA. El ROI de seguridad es desproporcionado en esos casos. El proyecto está en sus etapas iniciales. AGPL-3.0 sugiere un modelo de negocio open-core con una versión empresarial a futuro, similar a lo que hicieron Cilium con Isovalent o Tetragon. Las preguntas abiertas que la comunidad seguramente va a empujar son tres. Soporte para protocolos no-HTTP. ¿Funciona con gRPC, con bases de datos sobre TLS, con WebSockets? La respuesta inicial parece ser HTTPS only, pero la naturaleza de eBPF permitiría extenderlo. Observabilidad. Equipos de seguridad necesitan auditar quién usó qué secreto, cuándo, contra qué destino. Un buen sistema de logs y métricas integrado con Prometheus es imprescindible. Compatibilidad con clusters administrados. EKS, GKE y AKS imponen restricciones sobre privilegios del nodo. La adopción real va a depender de qué tan bien Kloak conviva con esos entornos. Más allá del producto puntual, Kloak forma parte de una tendencia mayor: el plano de seguridad migrando del runtime de la aplicación al kernel. Cilium hizo esto con redes. Tetragon con observabilidad de procesos. Falco con detección de amenazas. Era cuestión de tiempo que alguien aplicara la misma idea a la gestión de secretos. 📖 Resumen en Telegram: Ver resumen No exactamente. Vault sigue siendo más completo en almacenamiento, rotación, audit logs y modelos de PKI. Kloak resuelve un problema específico: que el secreto nunca toque la aplicación. Lo natural es complementarlos: Vault como source of truth y Kloak como capa de inyección invisible. El controller mantiene el mapeo placeholder → secreto en el control plane. Cuando un pod arranca, el data plane eBPF en su nodo carga las reglas correspondientes. La aplicación sigue usando el mismo placeholder en su config y el flujo funciona sin intervención manual. En principio sí, porque los DaemonSets con privilegios de eBPF son soportados en versiones recientes de los managed Kubernetes mayores. Conviene revisar la matriz de compatibilidad oficial antes de adoptarlo en producción. El overhead reportado es del orden de microsegundos por request, gracias a que eBPF ejecuta en kernel space sin cambios de contexto adicionales. En la práctica es indistinguible para la mayoría de cargas de trabajo. El label getkloak.io/hosts permite definir una lista blanca de dominios para cada secreto. Si el request va a un host fuera de esa lista, el placeholder no se traduce y la credencial nunca se inyecta. Es una defensa adicional contra exfiltración. La instalación con Helm de tres líneas y la ausencia de sidecars hacen que sea accesible incluso para equipos de dos o tres ingenieros. La barrera de entrada es baja comparada con desplegar Vault o construir un sistema custom. 📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse