Most systems will have variables that need to be stored securely; OpenId shared secret keys, connection strings, and API tokens to name a few.
These secrets must not be stored in source control. It is insecure and means they are sitting out in the open, wherever code has been downloaded, for anyone to see.
There are many options for managing secrets in a secure way:
❌ Bad Practices
Store production passwords in source control
Pros:
Minimal change to existing process
Simple and easy to understand
Cons:
Passwords are readable by anyone who has either source code or access to source control
Difficult to manage production and non-production config settings
Developers can read and access the production password
Tightly integrated into Azure so if you are running on another provider or on premises, this may be a concern. Authentication into Key Vault now needs to be secured.
✅ Figure: Good example - Overall rating 9/10
Avoid using secrets with Azure Managed Identities
The easiest way to manage secrets is not to have them in the first place. Azure Managed Identities allows you to assign an Azure AD identity to your application and then allow it to use its identity to log in to other services. This avoids the need for any secrets to be stored.
Stop storing your secrets with Azure Managed Identities | Bryden Oliver (14 min)
Pros:
Best solution for cloud (Azure) solutions
Enterprise grade
Access granted based on Azure AD permissions - no need to 'securely' share passwords with colleagues
Roles can be granted to your application your CI/CD pipelines at the time your services are deployed
Cons:
Only works where Azure AD RBAC is available. NB. There are still some Azure services that don't yet support this. Most do though.
✅ Figure: Good example - Overall rating 10/10
Resources
The following resources show some concrete examples on how to apply the principles described: