// preguntas
Lo primero que se suele preguntar.
Respuestas cortas y con sus límites. Lo demás está en la documentación.
Mi cluster ya tiene SSO.
kubelatch no lo sustituye ni pone otro encima: se da de alta como una aplicación más en el proveedor con el que ya entras en EKS, AKS o GKE, igual que Argo CD o Grafana, y entras con la sesión que ya tienes abierta. En EKS con IAM Identity Center, kubelatch se da de alta en el proveedor que tiene detrás (Okta, Entra ID, Google Workspace): el directorio propio de Identity Center solo ofrece SAML a las aplicaciones, y kubelatch no es compatible con SAML, así que ahí se entra con GitHub o con cuentas locales. Lo que pone es lo que a tu SSO le falta: permisos que caducan solos, un inventario de quién tiene qué y hasta cuándo, una fila legible por petición y la misma puerta para varias nubes, para la CI y para los agentes. Eso sí, los bindings que tu cluster da a los grupos del SSO siguen siendo cosa del cluster; que un permiso de kubelatch te meta por un tiempo en un grupo de esos bindings llega en la fase 1 · Free. Y cuando alguien se va, tu proveedor no se lo dice a kubelatch: deshabilitas su cuenta en «Usuarios», y mientras no lo hagas, lo que tenga sigue valiendo hasta que caduque.
Nosotros no compartimos kubeconfigs.
Entonces seguramente ya entras con tu SSO, y kubelatch parte de ahí: permisos con fecha de fin, una fila legible por petición y la misma puerta para todas las nubes, para la CI y para los agentes. Si en algún cluster todavía circula un kubeconfig de admin, esta comparativa cuenta qué cambia.
¿Por qué no Teleport?
Teleport hace más cosas: SSH, bases de datos, grabación de sesiones. Su edición Community solo pueden usarla empresas de menos de 100 empleados y de 10 millones de dólares de facturación, y el SSO por OIDC solo lo da Enterprise, con precio a consultar. kubelatch solo hace Kubernetes: un binario de Go y un Postgres, sin nada que se ejecute dentro del cluster, OIDC en Free y un precio público de 15 $ por persona y mes, facturado al año y desde 5 personas. Si necesitas servidores y bases de datos detrás de la misma puerta, o grabar hoy lo que muestra la pantalla de un exec, Teleport te encaja mejor, y la comparativa lo dice así. Que quede registrado lo que pasa dentro de una sesión está en el roadmap de kubelatch, en la fase 5 · Pro.
¿Esto es solo para equipos con agentes de IA?
No. Donde mejor se ve la idea es en un agente, que necesita un tope, un plazo y que quede registrado todo lo que hace. La caducidad, la auditoría y la revocación son las mismas para una persona y para un pipeline, y un equipo sin agentes usa todo eso sin tocar el servidor MCP.
¿Y DORA, NIS2 y el ENS?
Ninguna herramienta cumple una norma por ti, pero kubelatch deja por escrito parte de lo que esas normas exigen al acceso privilegiado: un usuario identificable en cada petición, permisos con fecha, cuentas de emergencia nominales y un registro que no sale de tu infraestructura (24 horas en Free; en Pro, lo que configures). Lo que falta, previsto para Pro en la fase 3, son las evidencias que pide el auditor: la exportación, las revisiones periódicas y el informe.
¿Es zero trust?
En parte. Lo principal, sí: cada petición que pasa por kubelatch se comprueba contra una credencial que caduca, sin caché de por medio; cluster-admin nunca pasa de 8 horas, y la pantalla «Permisos» cuenta los que no tienen caducidad para que no quede ninguno. Lo que todavía no tiene es lo que el NIST añade a la definición: decidir también según el dispositivo y con una política dinámica.