El marco de Strapi (hasta donde yo entiendo) requiere que se proporcione la contraseña de la base de datos en el lanzamiento. Por lo general, la contraseña se especifica en el archivo database.js de datos.js, así:
module.exports = ({ env }) => ({ defaultConnection: 'default', connections: { default: { connector: 'bookshelf', settings: { client: 'postgres', host: '/cloudsql/myDatabaseInstanceName', database: 'databaseName', username: 'databaseUsername', password: 'databasePassword', }, }, }, }); Por supuesto, esto no es muy seguro, ya que el archivo database.js de datos.js generalmente se envía al repositorio.
Por lo tanto, algunas personas inyectan la contraseña en el archivo database.js de datos.js, en lugar de almacenarla como una variable de entorno:
module.exports = ({ env }) => ({ defaultConnection: 'default', connections: { default: { connector: 'bookshelf', settings: { client: 'postgres', host: `/cloudsql/${env('INSTANCE_CONNECTION_NAME')}`, database: env('DATABASE_NAME'), username: env('DATABASE_USERNAME'), password: env('DATABASE_PASSWORD'), }, }, }, });Sin embargo, esto tampoco es muy seguro. En muchos entornos de tiempo de ejecución (incluido Google App Engine, que estoy usando), cualquier usuario del proyecto puede ver las contraseñas del entorno, en texto sin formato.
Idealmente, me gustaría almacenar la contraseña de la base de datos en una bóveda secreta (estoy usando Google Secret Manager), y de alguna manera proporcionar la contraseña de la bóveda al archivo database.js de datos.js en el lanzamiento. Pero no entiendo cómo implementar eso? ¿Es posible acceder a una bóveda secreta desde database.js de datos.js? O, ¿de qué otra manera podría inyectar de forma segura la contraseña de mi base de datos en Strapi?
¡Gracias!
La función de arranque se llama en cada inicio del servidor. Puede usarlo para agregar una lógica específica en este momento del ciclo de vida de su servidor.
console.log(env('HIGHLY_ENCRYPTED_PASSWORD')) y leer el resultado.Utilice los paquetes dotenv y dotenv-defaults .
Para valores predeterminados y no críticos, use el archivo ".env.defaults" y confirme este archivo en su VCS. Esto proporcionará una configuración de entorno con un solo clic para otros desarrolladores.
Si los miembros de su equipo desean anular los valores, deben usar el archivo ".env" ignorado por git en sus entornos de desarrollo locales. Esto evitará compromisos erróneos.
En su servidor, defina variables ambientales de forma externa y utilícelas sin incrustarlas en su código. Esto proporcionará seguridad a su entorno de producción en directo.
Como en los documentos de estos paquetes, puede usar cualquier valor de estos archivos o variables ambientales como
...., password: process.env.MY_PASSWORD, ....