 |
Anything that is secret or varies per environment is configuration (though not all configuration is secret). Configuration should never be part of the application. Therefore it doesn’t belong in version control and should never be committed. Inject these arguments dynamically as part of a CI / CD workflow and never expose them to the client.
Options
As with all software development, there are many ways to skin this cat and the best option for a given situation will depend on the time we’re given to implement it, the tools we have at our disposal, the type of arguments we’re storing, and our level of CI / CD adoption.
What we want to end up with is a dynamic, private configuration that is stored securely. The following are all much better options than simply hardcoding things directly in the application but an important prerequisite is that anywhere a secret or configuration is used in the app should be replaced with a dynamic reference to it using something like dotenv or phpdotenv.
A few places they shouldn’t be:
- Version control (Git, SVN etc).
- Memorized.
- Only in one place.
- In the browser (JavaScript etc).
- Emailed.
A few places they could be:
- In a secret manager like AWS Secrets Manager or Parameter Store
- Included in a Continuous Deployment workflow like Bitbucket Environment Variables
- A private file in S3
- A private file hosted by the enterprise that is requested during a build
Enforce the Principle of Least Privilege in all applications and follow the 12 Factor App principle and keep secrets secret, and separate configs from application code.