kubelatch¶

kubelatch da a las personas, a los pipelines de CI y a los agentes de IA permisos en Kubernetes con fecha de caducidad, sobre el SSO que ya tienes. Tu cluster ya sabe quién entra; kubelatch pone lo demás: hasta cuándo dura cada permiso, qué permite hacer y un registro de cada petición al API server.

En Kubernetes, un RoleBinding no caduca. En EKS y AKS la auditoría del cluster viene desactivada de serie, y si tienes clusters en varias nubes, cada una la guarda en su servicio y con su formato. Y un pipeline o un agente pueden entrar con una credencial compartida o prestada. kubelatch cubre esos huecos: los permisos llevan fecha de caducidad, 30 días si no eliges otra («Nunca» hay que elegirlo a propósito), y cluster-admin no pasa de 8 horas; cada credencial es de alguien y caduca sola; cada petición que pasa por kubelatch deja una fila que se lee de un vistazo, y una credencial revocada deja de funcionar en la siguiente petición.

De momento, los bindings que tus clusters ya dan a los usuarios y grupos de tu SSO siguen como están, sin caducidad, y lo que entra directo al cluster por ahí no queda en la auditoría de kubelatch. En la fase 1 del roadmap, un permiso de kubelatch podrá meter a una persona en esos mismos grupos solo mientras dure.

flowchart LR
    u["Personas y CI<br/>kubectl, k9s, Helm"] -->|"credencial propia"| kl["kubelatch<br/>proxy y auditoría"]
    adm["Administradores"] -->|"permisos"| kl
    kl -->|"actúa como esa persona"| k8s["Tus clusters<br/>EKS · GKE · AKS · k3s…"]
    kl --> pg[("Postgres<br/>inventario y auditoría")]

Qué te da¶

• Una credencial propia por persona o pipeline. Un token con su kubeconfig, con caducidad, que se revoca al momento. Los workflows de GitHub Actions obtienen la suya sin guardar ningún secreto en GitHub.
• Permisos por niveles. Seis roles de sistema (viewer, developer, debugger, secrets-reader, admin y cluster-admin), o, en Pro, roles propios compuestos con capacidades, sobre un namespace o todo el cluster. kubelatch mantiene el RBAC del cluster por ti.
• Inventario. Para quién es cada credencial, hasta cuándo vale y cuándo se usó por última vez.
• Auditoría por petición. Cada petición al API server queda registrada con quién, qué, dónde y el resultado, también los exec y port-forward.
• Agentes de IA con límites. Claude Code, Cursor o cualquier cliente MCP trabaja a través del servidor MCP de kubelatch, como bot o en tu nombre con solo los permisos que elijas; sus escrituras pueden esperar tu aprobación. Ver Agentes de IA.
• Cualquier cluster. Funciona igual en clusters gestionados (EKS, GKE, AKS) y autogestionados (kubeadm, k3s, RKE2, Talos): solo usa la API estándar de Kubernetes.
• Dos ediciones. Free con 2 clusters, 5 personas, 24 horas de auditoría y los roles de sistema; Pro por persona, con roles propios y una clave verificada sin conexión. Ediciones y licencia.

Por dónde empezar¶