Monopam Vault: Discovery, incorporación a Vault y rotación
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 9 → 10
ActualizaciónNuevo módulo sobre la operación del vault en producción: la clave del vault y el recifrado, la recuperación tras rotaciones fallidas, las sincronizaciones de secretos y los elementos compartidos, la codificación de tokens, las identidades de máquina y los leases de secretos dinámicos. El módulo incluye ahora diagramas y, al final, una lista de qué comprobar primero.
3 lecciones actualizadasduración
Actualización de contenido. Se notificó a los estudiantes inscritos.
La duración cambió de 24 a 26 minutos.
Cada secreto de la base de datos del inquilino se cifra con una clave que cada proceso de Monopam lee de su entorno al arrancar. Si no hay clave configurada, Monopam usa una clave integrada. Esa clave integrada viene dentro del producto, así que protege frente a una lectura casual, pero no frente a quien tenga a la vez un volcado de la base de datos y el software. Una instalación de producción configura su propia clave.
| Variable | Finalidad |
| --- | --- |
| `MONOPAM_VAULT_KEY` | La clave activa. Las escrituras nuevas la usan |
| `MONOPAM_VAULT_KEY_VERSION` | El número de versión de la clave activa. Un número mayor indica una clave más nueva |
| `MONOPAM_VAULT_KEYS` | Las claves antiguas, conservadas para poder leer las filas escritas con ellas |
Juntas forman el **anillo de claves**. Un superadministrador puede comprobar el estado con el estado de clave del mantenimiento del vault, que informa de la versión activa y de si la instalación usa una clave externa.
### Tres reglas que explican casi todos los incidentes
**1. Todos los procesos, y solo al arrancar.** El servidor web y cada gateway descifran secretos, así que todos necesitan el mismo anillo. El entorno se lee una vez al arrancar, por lo que un cambio no hace nada hasta que el proceso se reinicia. El síntoma clásico: la clave se configuró solo en el servidor web. Revelar una contraseña en el navegador funciona, porque el servidor web puede descifrar, pero SSH y RDP fallan, porque el gateway no puede. Configure la clave en todos los hosts, reinicie cada uno y planifique una ventana de mantenimiento.
**2. El trabajo sigue a la clave, nunca al revés.** Cuando la clave está en todas partes, un superadministrador lanza el trabajo de recifrado, que reescribe las filas existentes con la clave activa. Lanzarlo sin clave externa no aporta seguridad: las filas se reescriben con la clave integrada y se registra un aviso.
**3. Las claves antiguas se quedan hasta que el trabajo informe de cero fallos.** El resultado lista, por tabla, cuántos valores revisó, actualizó y fallaron. Un valor fallido es una fila que el trabajo no pudo descifrar, normalmente porque la versión de clave con la que se escribió falta en el anillo. El trabajo no toca esas filas. Si quita ahora las claves antiguas, esas filas quedan ilegibles para siempre. Añada la clave que falta a `MONOPAM_VAULT_KEYS`, reinicie, lance de nuevo el trabajo y quite las claves antiguas solo tras una ejecución con `FailedValues` a cero en todas las tablas.
::diagram pam-vault-key-change
### No hay recuperación
Una clave perdida no se puede recuperar, y todas las filas cifradas con ella quedan ilegibles. Guarde la clave fuera de Monopam, por ejemplo en un gestor de contraseñas con acceso restringido, antes de empezar el cambio, y trátela como la credencial más sensible que tiene.
> Consejo: lea el estado de la clave en el mantenimiento del vault antes y después del cambio. Antes le dice si la instalación usa siquiera una clave externa. Después, la versión activa debe ser la que usted configuró.
Una rotación cambia la contraseña en el destino y después ejecuta las automatizaciones que actualizan los sistemas dependientes, como un servicio o un grupo de aplicaciones que usa la cuenta. El ajuste `If Automation Fails` de la política de rotación decide qué ocurre cuando una de esas automatizaciones falla.
| Opción | Qué hace Monopam | Encaja cuando |
| --- | --- | --- |
| `Revert to the previous password` (por defecto) | Vuelve a cambiar el destino, de modo que vault y destino coinciden en la contraseña anterior | El sistema dependiente debe seguir funcionando y el destino tolera un segundo cambio |
| `Keep the new password` | Deja vault y destino con la contraseña nueva y marca el elemento para seguimiento | Un segundo cambio inmediato bloquearía la cuenta |
Piense en qué es realmente una reversión: un segundo cambio de contraseña en el destino segundos después del primero. En un sistema que bloquea la cuenta tras cambios rápidos ese segundo cambio es el peligroso. Ahí se conserva la contraseña nueva y se repara a mano el sistema dependiente.
### Cuando la reversión también falla
El evento de auditoría `Password Rotation Revert Error: Manual Intervention Required` significa que la automatización falló y que el intento de volver atrás también. Vault y destino pueden tener ahora contraseñas distintas, y Monopam no puede saber cuál acepta el destino.
No empiece a pulsar botones. Primero determine qué contraseña acepta ahora el destino. Después actúe según eso: `Reconcile` cuando el vault tiene el valor correcto y hay que alinear el destino, una reversión desde Password History seguida de `Reconcile` cuando el valor válido es el anterior, o un restablecimiento manual en el host. Probar contraseñas en el orden equivocado contra un sistema con umbral de bloqueo bloquea la cuenta y convierte un problema de rotación en una caída.
::diagram pam-rotation-outcomes
### Adónde viaja un secreto rotado
**Sincronizaciones de secretos.** Un elemento del vault puede sincronizarse con un almacén externo como AWS Secrets Manager. La sincronización solo se encola cuando la contraseña es definitiva: tras guardar, o tras una rotación correcta que no se revirtió. Una rotación fallida y revertida no envía nada, de modo que el almacén externo nunca ve una contraseña que vivió diez segundos.
**Elementos compartidos entre inquilinos.** Un proveedor de servicios puede hacer que un elemento de su inquilino principal sea utilizable en el inquilino de un cliente sin copiar el secreto. El modo decide qué puede hacer el personal del cliente.
| Modo | El inquilino del cliente puede |
| --- | --- |
| `Sessions only` (por defecto) | Abrir sesiones con la cuenta. El secreto no se muestra, no lo devuelve la API del vault y no se coloca en tokens de script |
| `Sessions and reveal` | Además leer el valor |
El secreto vive solo en el inquilino principal. La rotación, el historial y la reconciliación ocurren allí, y cada uso en el inquilino del cliente lee el valor vigente en ese momento, así que una contraseña rotada está al día en todas partes a la vez.
**Tokens en lanzadores y scripts.** Un token como `{{Vault.appadmin.Password}}` inserta el valor en bruto. En bruto es incorrecto siempre que el lugar donde se pega tenga su propia sintaxis. En una URL, una contraseña con `&` o `#` rompe la dirección. Añada un modificador de codificación: `{{Vault.appadmin.Password:url}}` codifica el valor con porcentajes, `:sh` y `:ps` lo hacen seguro dentro de una cadena entre comillas simples de shell o PowerShell, y `:base64` lo codifica para un transporte que descodifica Base64. Los modificadores no se pueden encadenar, y un modificador mal escrito se ignora sin error y devuelve el valor en bruto, así que pruebe con una contraseña llena de caracteres especiales.
> Consejo: tras una rotación fallida, lea la auditoría antes de tocar la cuenta. Si la reversión funcionó, vault y destino coinciden en la contraseña anterior y solo hay que reparar el sistema dependiente. Solo `Password Rotation Revert Error: Manual Intervention Required` indica que ambos pueden diferir.
Las personas revelan secretos en el navegador. Los pipelines, pods y operadores los leen del Secrets Store mediante una **identidad de máquina** (`Secrets` > `Identities`). La identidad inicia sesión, recibe un token de corta duración y lee lo que permiten sus **concesiones** (grants) sobre proyecto, entorno y carpeta.
### Elegir el método de inicio de sesión
| Método | La máquina se acredita con | Elíjalo cuando | Coste |
| --- | --- | --- | --- |
| Universal Auth | Un id de cliente y un secreto de cliente | El llamante puede estar en cualquier sitio, incluido un servidor de CI cuyo emisor de tokens solo es interno | Un secreto que hay que guardar y rotar a mano |
| OIDC | Un token firmado por su plataforma, verificado con las claves públicas del emisor y el claim vinculado | El emisor de la plataforma es accesible públicamente, como en los servicios de pipeline alojados | No se guarda nada. No funciona si Monopam no alcanza los documentos públicos del emisor |
| Kubernetes | Un token de cuenta de servicio del clúster | La carga de trabajo se ejecuta en un clúster | Monopam debe alcanzar el clúster |
Ejemplo: un equipo no quiere un token de larga duración en su repositorio en un servicio de pipeline alojado. Una identidad OIDC cuyo claim vinculado coincide con el origen del flujo da al pipeline un token de corta duración y no deja nada que filtrar. Su servidor de compilación propio también emite tokens, pero su emisor solo es visible dentro de la red, así que Monopam no puede validarlos. Ese servidor usa Universal Auth, con `Allowed IP ranges` ajustado a la red de compilación para que un secreto filtrado no sirva en otro lugar.
### Comportamiento que conviene conocer antes de un incidente
- **Los tokens sobreviven a los cambios en la identidad.** Deshabilitar una identidad, o `Rotate Secret`, detiene los inicios de sesión nuevos al instante. Los tokens ya emitidos siguen funcionando hasta que termina su `Token TTL (minutes)`. Un TTL corto es su tiempo real de contención.
- **`Rotate Secret` no tiene vuelta atrás.** El secreto antiguo muere de inmediato. Todo llamante que aún lo tenga falla con `Invalid client credentials.` hasta recibir el nuevo. Distribuya primero cuando pueda y nunca rote a la ligera una identidad compartida.
- **`Allowed IP ranges` se comprueba solo al iniciar sesión**, no en cada lectura. Detrás de un balanceador, la dirección del llamante es la primera dirección IPv4 de `X-Forwarded-For`. Si el balanceador no pone esa cabecera, todos los llamantes parecen el balanceador y una identidad restringida es rechazada. Corrija la cabecera. No añada la dirección del balanceador al rango, porque dejaría pasar a todos los que están detrás.
- **Los inicios de sesión fallidos pausan una dirección.** A partir del décimo fallo en cinco minutos, la dirección recibe `Too many failed logins` durante el resto de la ventana. Treinta pipelines tras una misma dirección NAT comparten ese destino, así que un trabajo en bucle con un secreto antiguo los detiene a todos.
- **Los rechazos llevan su código en el cuerpo.** Un rechazo de autorización en la API de máquina responde HTTP 400 con `"code":403` dentro. Los clientes deben leer el cuerpo.
- **`Restricted (never visible)` es un ajuste de pantalla.** Oculta un valor en la interfaz web. Una máquina con concesión lo recibe igualmente, tanto por la API de máquina como por la API compatible con Vault. Solo las concesiones limitan lo que una máquina puede leer.
### Secretos dinámicos
Un secreto dinámico (`Secrets` > `Dynamic`) crea bajo demanda una credencial de corta duración, por ejemplo un inicio de sesión de base de datos, y la entrega como una **concesión temporal** (lease). Cuando termina, Monopam revoca la credencial en el destino.
| Situación | Qué ocurre | Qué hace usted |
| --- | --- | --- |
| Una aplicación renueva su lease de base de datos una y otra vez | Cada renovación lo amplía, pero nunca más allá de la hora de creación más `Max TTL (minutes)` | Haga que la aplicación pida un lease nuevo y se reconecte antes de ese límite |
| El destino no era accesible cuando caducó el lease | El lease muestra `Revoke Failed`. Monopam no lo reintenta | Elimine a mano en el destino el inicio de sesión generado. Puede seguir existiendo |
| Se renueva un lease de token de Kubernetes | La renovación se rechaza | Pida un lease nuevo antes de que caduque el token |
::diagram pam-machine-lease
`Revoke Failed` es el estado que hay que vigilar. Es el único caso en que una credencial creada por Monopam puede seguir viva sin que nadie lo note.
### Qué comprobar primero
| Síntoma | Compruebe primero |
| --- | --- |
| Todos los llamantes de una identidad fallan con `Invalid client credentials.` | Si alguien usó `Rotate Secret`. El secreto anterior murió al instante |
| Muchos pipelines reciben `Too many failed logins` a la vez | Un trabajo en bucle con un secreto antiguo tras la dirección NAT compartida |
| Una identidad restringida es rechazada detrás de un balanceador | Si el balanceador establece `X-Forwarded-For` |
| Un cliente informa HTTP 400 donde se esperaba un rechazo | El cuerpo: `"code":403` es el rechazo de autorización |
| Una identidad desactivada sigue leyendo secretos | Sus tokens emitidos viven hasta que termina `Token TTL (minutes)` |