The Strapi framework (as far as I understand) requires the database password to be provided at launch. Usually, the password is specified in the database.js file, like this:
module.exports = ({ env }) => ({
defaultConnection: 'default',
connections: {
default: {
connector: 'bookshelf',
settings: {
client: 'postgres',
host: '/cloudsql/myDatabaseInstanceName',
database: 'databaseName',
username: 'databaseUsername',
password: 'databasePassword',
},
},
},
});
This of course is not very secure, as the database.js file is usually committed to the repo.
Therefore, some people inject the password into the database.js file, instead storing it as an environment variable:
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'),
},
},
},
});
However, this is also not very secure. In many runtime environments (including Google App Engine, which I am using) the environment passwords can be viewed, in plaintext, by any project user.
Ideally, I would like to store the database password in a secret vault (I'm using Google Secret Manager), and somehow provide the password from the vault to the database.js file at launch. But I don't understand how to implement that? Is it even possible to access a secret vault from database.js? Or, how else might I securly inject my database password into Strapi?
Thanks!
The bootstrap function is called at every server start. You can use it to add a specific logic at this moment of your server's lifecycle.
console.log(env('HIGHLY_ENCRYPTED_PASSWORD')) and read the output.Use dotenv and dotenv-defaults packages.
For default and noncritical values use ".env.defaults" file and commit this file into your VCS. This will provide a one-click environment setup for other developers.
If your team members want to override values, they should use gitignored ".env" file in their local development environments. This will prevent mistaken commits.
In your server, define environmental variables externally and use them without embedding them into your code. This will provide security to your live production environment.
As in the documents of these packages, you can use any value from these files or environmental variables as like
....,
password: process.env.MY_PASSWORD,
....