Cuentas y recuperación¶
Qué hacer cuando alguien se queda fuera de kubelatch, y cuando se queda fuera todo el mundo. Incluye las cuentas de emergencia y el acceso nativo a los clusters cuando kubelatch no está.
Cómo entran las personas¶
| Sin GitHub App | Con GitHub App (Login con GitHub) | |
|---|---|---|
| Personas | Usuario y contraseña. | «Entrar con GitHub». Solo miembros activos de la organización, con el 2FA que esta impone. |
| Contraseñas | Todas valen. | Solo las de las cuentas de emergencia. Las demás siguen en la base de datos, pero no sirven para entrar. |
| Alta | «Crear e invitar»: la persona fija su contraseña. | «Crear e invitar»: la persona vincula su cuenta de GitHub. |
| Bajas | Manuales: «Deshabilitar». | Automáticas al salir de la organización, o «Deshabilitar». |
| «Mi cuenta» | Cambiar contraseña. | «Vincular con GitHub». Cambiar contraseña, solo las cuentas de emergencia. |
Cambiar de modo no toca las cuentas: se vinculan una a una con enlaces de vinculación. Los bots no entran nunca: solo tienen credenciales (Usuarios y bots).
Sin GitHub no hay doble factor ni bajas automáticas: ver Modelo de seguridad.
Reglas de las cuentas¶
- Contraseñas: de 12 a 128 caracteres, distinta del login, sin reglas de composición. Se guardan con argon2id. Cada persona cambia la suya en «Mi cuenta» dando la actual; eso cierra sus otras sesiones. Ese cambio también admite 10 intentos por minuto por cuenta.
- Sesiones: cookie firmada de 12 h. Se cierran todas al instante al salir, cambiar la contraseña, usar un enlace de reset o de vinculación, desvincular GitHub, deshabilitar la cuenta o pulsar «Cerrar sesiones».
- Bloqueo: 5 fallos seguidos bloquean la cuenta 15 minutos (el quinto ya responde
429). Además, cada IP (o cada /64 en IPv6) tiene 10 intentos por minuto. Todo intento queda en el plano de control con la IP. - Último administrador: kubelatch no deja quitar el rol, deshabilitar, desvincular ni desmarcar como emergencia al último admin que puede entrar.
Cuentas de emergencia¶
Una cuenta de emergencia (break-glass) conserva la contraseña cuando GitHub está activado. Sirve para entrar si GitHub está caído o la App se ha desinstalado. Solo se marca desde la CLI. Los comandos usan $MGMT_KUBECONFIG, la ruta al kubeconfig del cluster de gestión (ver Instalar).
# marcar una cuenta existente
kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch exec -it deploy/kubelatch -- /kubelatch user set-break-glass <login>
# quitar la marca
kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch exec -it deploy/kubelatch -- /kubelatch user set-break-glass <login> --off
# crear una cuenta de emergencia nueva
kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch exec -it deploy/kubelatch -- /kubelatch user create rescate --admin --break-glass
Ten al menos una, con la contraseña en el gestor de secretos de la organización. No la uses en el día a día: no tiene doble factor. En «Usuarios» lleva la etiqueta emergencia, y entra desde «Cuenta de emergencia (contraseña)» en la página de login. Si la vinculas a GitHub y la persona sale de la organización, pierde el acceso como cualquier otra.
Cuando una persona se queda fuera¶
| Situación | Qué hacer | Quién |
|---|---|---|
| Contraseña olvidada | «Usuarios» → «Enlace de reset» (24 h, un solo uso). Compártelo por un canal seguro. Con GitHub, solo aplica a cuentas de emergencia. | Un admin |
| Cuenta bloqueada por intentos | Esperar 15 minutos, o un «Enlace de reset», que la desbloquea. | La persona / un admin |
| Cuenta de GitHub cambiada, perdida o vinculada por error | «Usuarios» → «Enlace de vinculación» (24 h). Si sale github_taken, esa cuenta de GitHub ya está vinculada a otra persona: «Desvincular GitHub» en la otra primero. |
Un admin |
| No puede entrar con GitHub | Lee el mensaje del login: «no es miembro activo» (falta en la organización o la invitación está pendiente), «no está vinculada» (hace falta un enlace de vinculación), «no exige doble factor» (activar el 2FA en la organización), «deshabilitada». | La persona / un admin |
| Enlace caducado o ya usado | La persona ve «Enlace caducado o ya usado» (410 en la API). Genera otro: anula los pendientes. |
Un admin |
| Persona que deja la empresa | Con GitHub, sacarla de la organización basta. Sin GitHub, o para adelantarse: «Deshabilitar». Nada la rehabilita solo aunque vuelva. | Un admin / GitHub |
| Credencial perdida o filtrada | «Revocar» en «Inicio» (la propia persona) o en «Credenciales» (un admin). La siguiente petición recibe 401 y los streams abiertos se cortan en menos de 10 s. Emitir otra. |
La persona / un admin |
| Bot comprometido | Revocar sus credenciales o deshabilitar el bot. | Un admin |
Cuando nadie puede entrar¶
La CLI del binario es la vía de rescate. Corre con la misma configuración que el servidor, aplica las migraciones pendientes y registra lo que hace en el plano de control sin actor. Úsala siempre con el kubeconfig explícito del cluster de gestión.
-
Contraseña nueva para un admin existente. También lo desbloquea, cierra sus sesiones y anula sus enlaces pendientes. No rehabilita una cuenta deshabilitada.
kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch exec -it deploy/kubelatch -- /kubelatch user set-password admin -
Con GitHub activado, esa contraseña solo vale si la cuenta es de emergencia. La CLI avisa si no lo es. Márcala:
kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch exec -it deploy/kubelatch -- /kubelatch user set-break-glass admin -
Si el único admin está deshabilitado, o no hay ninguno, crea otro y rehabilita al primero desde «Usuarios»:
kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch exec -it deploy/kubelatch -- /kubelatch user create rescate --admin --break-glass
Sin terminal (un runner, un script), usa --password-stdin con kubectl exec -i. Se quita exactamente un salto de línea final: una contraseña que termina en salto de línea se pasa con dos.
printf '%s' '<contraseña larga>' | kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch exec -i deploy/kubelatch -- /kubelatch user set-password admin --password-stdin
Con dos réplicas da igual en cuál se ejecute: la CLI va directamente a Postgres y no hace falta parar el servidor.
Si el pod no arranca (Postgres caído, configuración rota), el problema no es de cuentas. Mira los logs y el estado del pod:
kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch logs deploy/kubelatch
kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch describe pod
Acceso nativo de emergencia¶
kubelatch está en el camino de cada petición de las personas, pero nunca es la única vía a un cluster, y las cargas de trabajo no dependen de él. Antes de ir a producción, deja preparado y probado el acceso nativo de administrador:
- Clusters gestionados: la identidad cloud del proveedor (
aws eks update-kubeconfig,gcloud container clusters get-credentials,az aks get-credentials) con el rol de administrador de la plataforma, en el gestor de identidades de la organización y con MFA. - Autogestionados: el kubeconfig de administrador (kubeadm:
/etc/kubernetes/admin.conf; k3s:/etc/rancher/k3s/k3s.yaml; Talos:talosctl kubeconfig) en un vault con acceso auditado, o SSH a un nodo del plano de control.
Ese acceso sirve para reparar kubelatch (por ejemplo, volver a aplicar el bootstrap), actuar cuando kubelatch está caído y hacer lo que kubelatch no permite: namespaces protegidos, nodos, --as. Su uso queda en la auditoría nativa del cluster, no en la de kubelatch: revísalo con la misma disciplina.
Cuando kubelatch funciona, prefiere un permiso cluster-admin de 8 h como máximo, que sí queda auditado: Conceder permisos.
Si se pierde la clave de cifrado¶
Sin KUBELATCH_ENCRYPTION_KEY, todo el mundo vuelve a iniciar sesión y hay que volver a pegar los tokens de cada cluster. Las contraseñas, las credenciales klt_, los permisos y la auditoría no se ven afectados. El procedimiento está en Actualizar y copias de seguridad.