Recuperación de secretos de Vault tras pérdida de unseal keys con Shamir backup

El problema real

#

Hace unos meses configuré Vault en mi servidor doméstico para centralizar secretos. Todo funcionaba bien hasta que me pasó lo inevitable: cambié de máquina, reformatee discos, y las unseal keys desaparecieron. El Vault seguía ahí, pero sellado. Sin acceso a los datos.

Pensé que todo estaba perdido. No era así. Aquí te cuento cómo lo solucioné.

Entendiendo Shamir Backup

#

Cuando inicializas Vault, tienes dos opciones para los unseal keys:

• Guardarlos en un archivo (mala idea)
• Usar Shamir Secret Sharing (la que deberías usar)

Con Shamir, Vault genera N claves de las cuales necesitas K para sellar el vault de nuevo. Por defecto es 5 claves, 3 necesarias.

El truco está en que durante la inicialización, Vault también genera un Recovery Key Backup en formato JSON. Este backup es la llave maestra.

Paso 1: Localizar el backup de Shamir

#

En mi caso, la encontré en los backups de la máquina anterior:

cat vault-init-backup.json

El archivo debe contener algo como:

{
  "unseal_keys_b64": ["...","...","..."],
  "recovery_keys_b64": ["..."],
  "root_token": "hvs.xxxxxx"
}

Si no tienes este archivo, tienes opciones limitadas (más sobre eso después).

Paso 2: Verificar el estado del Vault

#

vault status

Output esperado:

Key                      Value
---                      -----
Seal Type                shamir
Sealed                   true
Unseal Progress          0/3

Paso 3: Reconstruir el quórum

#

Necesitas introducir K claves de unseal. Con el backup de Shamir, tienes dos caminos:

Opción A: Usando las unseal keys originales

vault unseal <unseal_key_1_b64>
vault unseal <unseal_key_2_b64>
vault unseal <unseal_key_3_b64>

Opción B: Usando recovery keys (si iniciaste con auto-unseal)

Si habías configurado auto-unseal, simplemente reinicia el Vault. El mecanismo externo lo desellará automáticamente.

Paso 4: Generar nuevas unseal keys

#

Una vez desbloqueado, haz esto INMEDIATAMENTE:

vault operator rekey -init -key-shares=5 -key-threshold=3

Esto inicia el proceso de rekeying. Necesitarás proporcionar el token raíz actual.

Completa el proceso:

vault operator rekey -nonce=<nonce> <recovery_key_1>
vault operator rekey -nonce=<nonce> <recovery_key_2>
vault operator rekey -nonce=<nonce> <recovery_key_3>

Guarda las NUEVAS claves en un lugar seguro. En mi caso, encryptadas en un NAS y en un usb offline.

Paso 5: Validar acceso a secretos

#

vault login <token_raíz>
vault secrets list
vault kv get secret/ruta/a/secreto

Si ves tus secretos, felicidades. La recuperación funcionó.

Si no tienes el backup

#

Aquí está lo crudo: sin el backup de Shamir y sin acceso a K unseal keys, Vault es irrecuperable. No hay puertas traseras.

Mi recomendación:

• Guarda el archivo JSON de inicialización en múltiples ubicaciones
• Encriptalo con GPG o similares
• Mantén copias en USB offline
• En producción, usa auto-unseal con un KMS externo (AWS, Azure, GCP)

Lecciones aprendidas

#

Este incidente me hizo replanificar mi estrategia de disaster recovery:

1. El backup de inicialización es tan crítico como la base de datos misma
2. Documentar dónde están las claves (sin exponerlas)
3. Probar regularmente que puedo recuperar todo
4. En homelab, auto-unseal con un servicio externo simplifica mucho

La seguridad no es solo encripción. Es también tener un plan para cuando las cosas se rompan.

Si te encuentras en esta situación, no entres en pánico. El backup existe por una razón.