This is more a curiosity/query-for-information than anything; apologies if it’s thus a little malformed:

This is relevant to a useful API-querying library that can be shared across multiple teams within the company.

Consider the scenario wherein all configuration is propagated via environment variables. Anything that needs something like an environment-specific URL just pings (in the case of Python) os.envion.get("ENVIRONMENT_SPECIFIC_URL"). But, this presents a problem for security-sensitive environment variables like API keys. Even if the means of populating the environment is itself secure (e.g., decrypting an encrypted secrets file), the decrypted secret is sitting in a persistent environment and can be accessed by anything that manages to read said environment. This probably isn’t a problem in most cases, but it isn’t ideal.

Honestly, I think environment variables are almost ideal; you leave their population to whatever you want, while the configured code can be used anywhere.

  • Is there a means of using environment variables… securely?
  • Are there other ways to maintain this separation of configuration and application code?

I’ve considered a few things, some funnier than others:

  • Environment variables that are populated on build, but discarded afterwards. This too tightly couples configured code by requiring it to only check the environment at build-time.
  • Using a secrets manager. This also couples configured code. I don’t want to have to e.g. use the google secrets module whenever a request is made
  • A configuration class. ” “
  • Here’s the funny one I really want to ask about: Encrypted environment variables that are decrypted when accessed and encrypted again. I don’t even know how this would work. Would it be something running in the background constantly? No, hopefully not. Something that neatly injects itself into whatever environment variables are accessed … maybe? Maybe something like overriding an attribute?

5