La gestió segura de secrets és un dels grans reptes en entorns DevOps, cloud i Kubernetes. HashiCorp Vault s’ha convertit en una de les eines més utilitzades per protegir credencials, API Keys, certificats i configuracions sensibles de manera centralitzada i segura.
Soc Òscar Mas i si estàs llegint això, és probable que tinguis fitxers .env escampats per tot arreu o, pitjor encara, algun "password" escrit en un fitxer de text pla (tranquil, això li passa a tothom).
Avui anem a parlar de HashiCorp Vault, l'eina definitiva per posar ordre a tot aquest caos.
Què podem guardar a Vault?
Abans de començar, ens hem de preguntar: què guardem exactament a Vault?, i no hi ha una resposta a aquesta qüestió hi ha diverses respostes:
Contrasenyes i Credencials
Des del login de l'administrador de la base de dades fins a les claus d'accés de l'usuari de test.
Tokens d'API
Totes aquelles "API Keys" de serveis com Stripe, AWS o SendGrid que mai haurien d'estar al codi font.
Certificats SSL/TLS
Vault pot gestionar (i fins i tot generar!) els teus certificats per assegurar que les comunicacions entre els teus serveis siguin segures.
Configuracions sensibles
Hi ha paràmetres de configuració que, tot i no ser una contrasenya, no vols que siguin públics (com ara URLs internes o ports específics).
A part d'aquestes característiques (que no són poques), una de les coses més importants, és el "Secret Sprawl" (la dispersió de secrets). Aquest és el problema que Vault soluciona; és tenir la seguretat centralitzada en un sol punt, en comptes de tenir-la en mil eines o llocs diferents.
Si encara et preguntes si val la pena l'esforç d'implementar-lo, aquí tens tres motius de pes que et faran dormir més tranquil a les nits:
Adeu als secrets escampats: La missió principal és evitar que les credencials visquin en fitxers de text, dins del mateix codi o en variables d'entorn insegures.
Auditoria total (qui, què i quan): En seguretat, la traçabilitat ho és tot. Vault et permet saber exactament qui ha demanat un secret, en quin moment ho ha fet i des de quina IP. Si passes res estrany, tens la informació per poder investigar-ho.
Xifratge simplificat (Transit): Imagina que la teva aplicació ha de guardar dades bancàries. En comptes de programar tota la lògica criptogràfica (que és complicat i perillós), envies la dada a Vault, ell la xifra i te la torna. L'aplicació mai gestiona les claus mestres, només demana el servei.
Què és el Unseal a Vault?
A partir d'aquests punts, és molt important tenir clar que és el Unseal en Vault.
L'Unseal és el procés d'introduir les claus necessàries per “desbloquejar” el sistema de Vault i que pugui començar a servir secrets. Per defecte, Vault utilitza un sistema anomenat Shamir's Secret Sharing: això és, que la clau necessària per desbloquejar Vault, es divideix en diverses parts i en necessites un mínim de claus per poder obrir-lo. Això evita que una sola persona tingui el control total.
Has de ser conscient que cada cop que es reinicia el servei de Vault, és necessari introduir aquestes claus, si no Vault no podrà servir els secrets que té emmagatzemats. Com que pot ser que el sistema és reiniciï en un moment que no puguem introduir manualment les claus, existeixen diferents formes d'automatitzar el Unseal i no haver-ho de fer manualment:
- Scripts Custom (totalment desaconsellat): Podries fer un script que enviï les claus automàticament en arrencar. És funcional i molta gent ho fa al principi, però és un risc enorme: si algú entra al servidor de l'script, té les claus de tot el teu regne. És com deixar la clau de la caixa forta sota la catifa de l'entrada.
- Servidor de Transit: Consisteix a fer servir una altra instància de Vault independent per guardar les claus de la primera. És una solució elegant si ja tens un ecosistema de Vault a l'empresa, delegant la confiança d'un a l'altre Vault.
- Serveis Cloud (KMS): Aquesta és l'opció més professional i segura en entorns al núvol. Utilitzem serveis com AWS KMS, Azure Key Vault o Google Cloud KMS. Vault delega el desxifrat de la seva clau mestra a aquests serveis gestionats. És extremadament segur perquè tot queda protegit per les polítiques d'accés (IAM) del teu proveïdor de cloud.
Mètodes d'autenticació de Vault
Vault no té una llista d'usuaris “estàtica” per defecte (a part del root), per poder accedir al seu sistema. Utilitza diferents mètodes d'autenticació per validar la teva identitat i donar-te un Token, com per exemple:
Tokens (El mètode natiu)
És el cor de Vault. Al final, facis servir el mètode que facis, Vault et donarà un Token
Userpass
El mètode més clàssic. Creem un usuari i una contrasenya directament dins de Vault.
LDAP / Active Directory
Si treballes en una empresa gran, segurament ja teniu un Active Directory. Vault es pot connectar al vostre sistema, per fer servir les seves credencials corporatives per entrar.
Kubernetes
Si fas servir K8s, Vault pot validar la identitat d'un Pod mitjançant el seu Service Account.
AppRole
Aquest és el mètode preferit per a les màquines o aplicacions. En lloc d'un usuari/contrasenya, l'aplicació fa servir un RoleID i un SecretID (com si fos un usuari i contrasenya per a robots).
GitHub
Molt popular entre desenvolupadors.
Diferències entre KV1 i KV2
Un altre punt important, és saber que quan guardem dades a vault, hi ha dues formes de guardar-les, fent servir KV1 i KV2 (KV significa: Key-Value) i la diferència és:
- KV1: Només guarda el valor actual. Si escrius sobre una clau existent, el valor antic desapareix per sempre.
- KV2: Cada vegada que canvies un secret, Vault no esborra l'anterior, sinó que crea una versió nova (v1, v2, v3...). Pots recuperar un valor antic en qualsevol moment.
Static and Dynamic Secrets
Per tancar, cal entendre que Vault no només guarda dades (secrets, configuracions, etc...), existeix un món meravellós anomenat "dynamic secrets":
- Static secrets: Són els de tota la vida. Tu guardes una contrasenya, la muntes a Vault i allà es queda fins que tu la canviïs manualment.
- Dynamics Secrets: Aquí és on passa la màgia. Vault pot generar unes credencials úniques per a un usuari (per exemple, per a una base de dades SQL) que només existeixen mentre es fan servir o durant un temps predefinit i s'autodestrueixen després. Si algú les roba, no li serviran de res al cap de poca estona.
Espero que aquest article us hagi servit d'ajuda i si més no, us hagi estat útil per acabar d'aclarir conceptes.