3 ms·
Something I have done for secrets is use a syntax in environment variables to tell the process to go a key vault for the secret. So we can have FOOPW=pw1 whe
by dagss 2y ago
Something I have done for secrets is use a syntax in environment variables to tell the process to go a key vault for the secret.
So we can have
FOOPW=pw1
when testing locally, but
FOOPW="{vault1:secret1}"
in production. Env vars are processed simply by running a regex with callback that fetches secrets from vaults. This is quite flexible and has the advantage of being able to inject the secrets in the same place as other configuration, without actually having the secrets in environment variables or git etc (even encrypted)
- pak9rabid 2y agoHah! I've done something similar. In my case, I could have something like this in my .env file: SOME_CONFIG_OPTION = @AWS::some_config_option And I've written a config library that knows that when a config value starts with `@AWS::' it needs to resolve the config option to an actual value by reaching out to AWS's Secrets Manager service and looking it up there, in which case it receives the value and caches it locally so that subsequent references to this configuration option don't require an additional call out to the cloud. It works surprisingly well.