Secretos en runtime: el caso del .env vacío
Cloud Vault resuelve los entornos cuando un servicio hace ignite — versionado, delimitado, auditado. Tu repo no vuelve a guardar un secreto.
Cada credencial filtrada que hemos ayudado a rotar tenía la misma historia de origen: se escribió en un archivo, y el archivo viajó. A un repo, a una imagen, a una laptop que salió del edificio.
Cloud Vault parte de una premisa distinta: la configuración es un asunto de runtime, no un artefacto de build. Tu .env queda vacío. Cuando un servicio llama ignite(), el runtime trae el árbol de entorno de este servicio en este entorno — development, staging, production — y lo funde en el dependencies.config de solo lectura.
Qué ganas con eso
Nada sensible persiste. Los secretos viven en la memoria del proceso exactamente mientras corre el servicio. No en el repositorio, no en la capa de la imagen, no en disco.
Cada lectura se audita. Quién trajo la llave de pagos de producción, cuándo, desde dónde — una consulta, no una investigación forense.
La rotación deja de ser un deploy. Cambias la contraseña de la base de datos una vez en Vault; cada servicio que la consume la toma en su siguiente boot. Sin tren de deploys coordinado, sin cuarenta .env divergiendo.
Los entornos están versionados. Compara staging contra production. Ve qué cambió antes del incidente, no después.
La salvedad honesta
El desarrollo local sigue funcionando con un .env normal — el SDK lo lee cuando no hay Vault configurado. El mismo código, ambos caminos. El vault es cómo la plataforma amplifica el runtime, nunca un muro entre tú y tu laptop.
