Administración de variables de entorno con SecretsFoundry

Escribí sobre las diferentes formas de administrar las variables de entorno anteriormente en mi correo aquí. Para facilitarnos la gestión de la configuración en nuestra startup en Verdadera fundición, escribimos una pequeña herramienta llamada SecretsFoundry que realmente ha hecho que todos los equipos de aplicaciones puedan mantener sus configuraciones en Git sin problemas. Pensamos que podría ser útil para otros equipos de desarrolladores y, por lo tanto, decidimos de código abierto eso.

Antes de entrar en detalles, será bueno entender cuál es el problema que resuelve SecretsFoundry. Cada aplicación tiene alguna variable de configuración sensible e insensible que debe proporcionarse a la aplicación cuando se está ejecutando. Para las variables no sensibles, las personas tienden a colocar las variables en un archivo y luego cargarlas en la aplicación utilizando bibliotecas como dotenv. En el caso de las variables no confidenciales, las personas almacenan los valores en algunos administradores secretos, como AWS SecretManager o Hashicorp Vault, y luego escriben el código de la aplicación para extraer los secretos del almacén. El otro enfoque consiste en hacer que algún sistema externo incorpore las variables del almacén secreto al entorno de la aplicación, en cuyo caso el dominio de las variables de entorno pasa a ser más una responsabilidad de DevOps y los desarrolladores pierden el control sobre él, lo que genera más errores y dificulta la depuración cuando surgen problemas.

SecretsFoundry intenta resolver los problemas anteriores haciendo lo siguiente:

Todas las claves sensibles y no confidenciales pueden estar en un solo archivo.

Para las variables no sensibles, puede colocar las variables directamente. Para las variables sensibles, colocamos la ruta en el almacén secreto como el valor de esas variables. De esta manera, le decimos a secretsfoundry cómo obtener esos valores. Un ejemplo de este tipo de archivo sería:

archivo.env

NODE_ENV = desarrollo
ANFITRIÓN = servidor local
DB_NAME = example_app_db
DB_USER = $ {aws-secret: /development/example_app/db_user}
DB_PASSWORD = $ {aws-secret: /development/example_app/DB_password}

En el ejemplo anterior, el DB_USER y el DB_PASSWORD reales se almacenan en AWS Secrets Manager. Los desarrolladores pueden mencionar la ruta en el archivo.env y secretsfoundry la buscará automáticamente.

No hay código específico de la aplicación para obtener variables de entorno

Secretsfoundry funciona al infundir los valores reales en el entorno de la aplicación antes de que se inicie, en lugar de hacerlo dentro de la aplicación. Esto tiene dos ventajas:

1. No hay dependencias en la aplicación y no necesitamos agregar bibliotecas en la multitud de idiomas diferentes.
2. En caso de que secretsfoundry no pueda encontrar una determinada variable de entorno, la propia secretsfoundry produce un error y proporciona una señal temprana de mal funcionamiento a todos los sistemas de implementación, como Kubernetes. De lo contrario, depende de la aplicación realizar la validación y gestionar los errores.

Soporte para varios administradores secretos

SecretsFoundry se integra con AWS Parameter Store, AWS S3, AWS SecretsManager y Hashicorp Vault para la administración de secretos. Añadir un nuevo almacén secreto es bastante sencillo y tenemos previsto ampliar el soporte para GCP y Azure Vault en el futuro.

Uso de SecretsFoundry

La forma de usar secretsfoundry es:

secretsfoundry run -c «node start.js»

o si tiene varios comandos en su script de inicio:

secretsfoundry run -s «node run_migration_script && node start.js»

Cuando lo hacemos secrets foundry run, busca un archivo.env en ese directorio e imprime los valores de las variables. Si hay un argumento -c o -s, los infunde en el entorno de esa aplicación. Por lo tanto, si tenemos en cuenta el archivo.env que escribimos anteriormente, al ejecutar secretsfoundry en ese directorio, se generará

secretsfoundry run

NODE_ENV = desarrollo
ANFITRIÓN = servidor local
DB_NAME = example_app_db
DB_USER = administrador
DB_PASSWORD = contraseña

Podemos tener una pequeña aplicación de muestra en start.js que tiene un aspecto similar al siguiente:

secretsfoundry run -c «node start.js»

SecretsFoundry también puede cargar cualquier otro .env. <stage>archivo usando

secretsfoundry run — stage= <stage>

SecretsFoundry puede recoger archivos de configuración de otro directorio usando

secretsfoundry run -p <Ruta al directorio de configuración, que contiene los archivos.env. secretsfoundry run -p

También puede tomar la ruta de entrada a un archivo que puede estar en formato.env/ json/ yaml y enviar las variables resueltas a un archivo diferente. Lo usamos para integrarnos con varios sistemas de Kubernetes, sobre los que escribiré en otro blog.

<Input file containing variables (.env/json/yaml) >secretsfoundry run -i -o <output_file>

SecretsFoundry necesita credenciales para obtener los parámetros de SecretStore, por lo que tendrá que proporcionar esas variables manualmente a su entorno.

Instalación y documentación

Puedes descargar secretsfoundry usando npm o yarn ().https://www.npmjs.com/package/secretsfoundry)

npm install -g secretsfoundry

SecretsFoundry reside en esto Repositorio Github y sus documentos se pueden encontrar en https://truefoundry.gitbook.io/secretsfoundry.

Prueba SecretsFoundry y cuéntanos tu experiencia. Lo hemos estado utilizando internamente de forma bastante extensa con AWS Parameter Store; sin embargo, la integración de Hashicorp Vault no se ha probado bien. Pruébalo y avísanos si encuentras algún error o tienes alguna solicitud de funcionalidad.

Publicado originalmente el Mediano