// comparativa
kubelatch frente al kubeconfig compartido.
Muchos equipos empiezan con un kubeconfig de admin que pasa de mano en mano, y después, cuando crecen, con una ServiceAccount creada a mano para cada persona. Las dos cosas funcionan el primer día; esta página muestra lo que deja abierto cada una, pregunta a pregunta, junto a lo que hace kubelatch.
// ocho preguntas
Frente a frente.
| Pregunta | Kubeconfig de admin compartido | ServiceAccounts hechas a mano | kubelatch |
|---|---|---|---|
| Quién lo tiene | Quien consiguió una copia: de un chat, de un portátil, de un secreto de CI. Nadie lleva la lista. | Una por persona, mientras alguien se acuerde de crearla, y de borrarla. | Cada credencial tiene dueño y nombre, y aparece en la lista con lo que alcanza, cuándo caduca y cuándo se usó por última vez. |
| Caducidad | Lo que dure el certificado o el token que lleva dentro: a menudo un año o más. | La que se puso al crear el token; un token de larga duración no caduca nunca. | Siempre. Por defecto, 30 días como mucho para una persona, 90 para un bot y 1 hora para un job de CI. |
| Qué ve el API server | Una identidad, la misma para todos los que lo tienen. | system:serviceaccount:…, una por persona, con nombres por convención. | A la persona real, user:ana, solo con los grupos de sus permisos activos. La auditoría nativa del cluster la registra como el usuario suplantado. |
| Revocación | Kubernetes no revoca certificados de cliente: rotas credenciales en todo el cluster, o esperas a que caduque. | Borrar a mano cada token o ServiceAccount, si sabes cuál. | La revocas y su siguiente petición recibe un 401; un exec o un watch abiertos se cortan en menos de 10 segundos. |
| Auditoría | La auditoría nativa del cluster, si está activa, con un solo nombre para todos. | La auditoría nativa de cada cluster, si está activa: un formato y un sitio por proveedor. | Cada petición, registrada antes de llegar al cluster, igual en todos los clusters, con un Audit-ID que comparte la auditoría nativa. Free muestra las últimas 24 horas. |
| Pipelines de CI | Una copia del kubeconfig en los secretos del CI. | Un token de ServiceAccount en los secretos del CI. | GitHub Actions canjea su token OIDC por una credencial que dura 1 hora por defecto, y en GitHub no se guarda nada. Otros sistemas de CI usan una credencial de bot, de 90 días como mucho. |
| Agentes de IA | El agente recibe el kubeconfig, y todo lo que permite. | El token de alguien acaba en el agente, y la auditoría no distingue al agente de ese alguien. | A través del servidor MCP, como tú, con los permisos que elijas, en solo lectura por defecto; sus escrituras pueden esperar tu aprobación. |
| Lo que cuesta montarlo | Nada: ya existe. | Una ServiceAccount, un binding y un token por persona, en cada cluster. | Un chart de Helm y un Postgres en un cluster de gestión, y después un comando por cluster para darlo de alta. |
Cada celda de kubelatch sale de la documentación: identidad, credenciales, caducidad y revocación, auditoría, CI, agentes de IA e instalación.
// el caso honesto
Cuándo basta con el kubeconfig compartido.
Una persona, un cluster desechable y nada que demostrar a nadie: un cluster kind en tu portátil, un laboratorio que borras el viernes. kubelatch es un servicio más y una base de datos que mantener; para ese caso es más de lo que necesitas, y preferimos decírtelo.
- Como es un proxy, está en el camino de cada petición: si kubelatch cae, las personas y el CI pierden el acceso a través de él, aunque las cargas de trabajo siguen funcionando.
- Necesita un cluster de gestión con Kubernetes 1.30 o posterior, y un Postgres.
- No sustituye el acceso de emergencia propio de cada cluster, que tienes que conservar, y probar.
// el paso
Pruébalo en un cluster que puedas tirar.
El tutorial local monta kubelatch en tu máquina con un cluster kind desechable: te das un permiso, usas kubectl a través de él, miras la auditoría y revocas la credencial. Unos 15 minutos, más las primeras descargas.
Y también: kubelatch frente a las pasarelas de acceso.