This is terrible advice. Code and config should be separate. Otherwise you can't deploy the same code to a different environment.
If you want to run local environment you can simply create your own configuration.
I don't really see what you gain by moving configuration files into a separate repository.
Externalizing config forces you to cleanly handle local environments as well. There's nothing special about them.
I generally recommend having an env.example file listing out required environment variables with sensible local defaults. This eases onboarding a new developer or even an existing developer on a new machine.
> I don't really see what you gain by moving configuration files into a separate repository.
Because config and code should be kept separate. Updating the database that your production app is using is not a code change. It's a config change.
Setting up a new CI environment should not require pushing new code.
If you have a production issue in version X, separating code and config allows you to reproduce it using an isolated database/mq/foobar service. It's exactly the same code.
The Twelve-Factor Methodology is a sensible set of guidelines/defaults for building a modern app, as written by Heroku.
Don't blindly follow it As It Was Written without thinking. Seriously, do what works. Use your brain. Using this statement as an argument against other methods is sending the wrong message.
This would be better if it could use the aliases directly, so you could have one config across N environments and separate them by AWS keyspace.
Having to embed the full KMS path for each key gains you the secret management they claim (which is a good thing) but sacrifices ease of use. That said, aliases wouldn't help with missing secrets or misconfiguration across environments, and its a lot easier to audit string-for-string to match your KMS store, so either approach has its pluses and minuses.
[0] https://github.com/StackExchange/blackbox
P.S.: I think the image looks aesthetically pleasing, but why is it there? It's a scaled-down 1,600x680px image that costs me 140KB and doesn't add anything to the article; what's worse is that it's not even a nice banner image, it's just smack dab in the middle of the article.
What year is it?
Storing your secrets in plain sight*
* as long as plain sight includes a remote service call at some point
You can do this with the inhouse AWS tools, awscli and boto3 for python This was for use within a python lambda function so i used the secrets in a seperate file, but no loss of generality here.
* Create your keys in KMS via Web UI or otherwise * encrypt your secrets before commit aws kms encrypt --key-id alias/TokenKey --plaintext fileb://unencrypted_token --output text --query CiphertextBlob > encrypted_token
Decrypt the token from your python lambda function with boto3
kms = boto3.client('kms') token = kms.decrypt(CiphertextBlob=base64.b64decode(token_encrypted))['Plaintext'].decode('ascii')
The blob from KMS contains the appropriate fields for decryption from their service. Give the lambda role rights to decrypt with the key.
It also states that KMS isn't a requirement, you can use Vault too.
In case of catastrophic KMS failure we can always manually replace secrets with plaintext and revoke them afterwards.
