App Configuration, where does it go? Config files, env vars, external service?

How are you storing your configuration? In code, config files, external services like AWS ParameterStore, Secrets Manager, Azure App Config, Key Vault? Let me know!

Finally! ♥

what credentials is your app using to access the external configuration store, and where are those stored? if your app locally caches configuration, where does it cache it, and why is that anymore secure than a flat file? the idea of storing credentials is a key vault suddenly got very popular, but I haven't heard anyone explain how it's actually better - it sounds like it's just creating a new version of the same problems? plus, if there is actually a good solution to this problem, why aren't APIs and service just natively using the same strategy? I would love to see a video that actually explains these things.

I am really keen on reducing complexity in my apps as much as possible. So I like env variables the most. They are likely the oldest tech of all configuration options you mentioned, they are available in all systems, they are reliable, you can put them in your deployment pipelines and with a bit of fiddling you can even do some more. Under Linux you have up to 128 kb (131k Characters) available. I once did a base64 on a json config file and put it as an env variable. Worked like a charm (as long as you don't do Windows, which has a limit of 32k Characters...)

How can we make the communication between services and Configuration service secure?

After fetching the secrets from configuration service (ex: AWS ParameterStore), where do you store them? The secrets that I am trying to store are static, and so there is no point of keep calling the ParameterStore to fetch the same secrets every time. For the storing mechanism, I am thinking either store these secrets in local variable of the application, in-memory cache such as Redis, or environment variables using some injection sidecar container. Any recommendation?

Caching sensitive data / secrets gives a new problem right? How to protect those secrets.

Hi Derek, thanks for the video! I don't think many people think about availability in the context of application configs and it is definitely worth it, especially in the case of scalable applications...

Could you give any example of what could be that config store? 🤔

I also think that it is worth of reconsideration of what COULD be stored in env vars even if it's kind of "against the rules" e.g. if we have a virtual machine hidden in some virtual private network and limited access, one could say that it is ok if we store some technical user credentials etc. without paying extra fees for azure key vault or aws secrets storages.

On azure we use a keyvault for each domain. At first we had a pipeline deploy with token replace on the appsettings. now we have added an identity to each app so it can be given acces to its keyvault at runtime. That is by far the most secure way of doing it. We use an validator in the startup so it fails hard if an required secret is not found in the keyvault. this only happens if you deploy stuff for the first time. We only read the keyvault at startup so changes only apply on restart of the app.
Locally we use secretmanager so we do not need to check in appsettings into the repository.

We use Azure App Configuration to populate environment variables in k8s during deployment for config, and Azure Key Vault for secrets, and managed identity where possible.

AAC has a 30k req/hr limit though which is causing us headaches as we try to use it for feature flag management, even though it refreshes in the background rather than every time you need to check a flag. They seem to want you to make an AAC instance per service, which is nuts.

I'm currently writing something to get the config out of AAC and broadcast it to all services as it changes but trying not to over engineer something that should be so simple.

Where do you store the credentials to connect to a configuration store itself?

I mainly use environment variables, but also key vaults. We've configured Kubernetes to fetch secrets automatically from key vaults based on certain roles, and those secrets are used as arguments when starting apps. So the apps themselves doesn't integrate with the key vaults.

I mostly use Laravel and its strategy goes like this:
1) .env file with secrets and other env-specific things

2) those get loaded and saved to an in-memory config object so they can be modified at runtime

3) Classes that depend on the above convifuration are usually injected into the DI container with the default config but if you want to both change the config and keep resolving the class from DI for testing purposes, you can modify the config just before resolving the class

Us in Spring Boot land have access to some really great facilities for handling configuration. Using multiple profiles and profile groups, you can provide slices of configuration and specify them as part of the deployment e.g. by environment, datacenter, region, and even hot reload the application if you are able to mount property customizations as a file that can change (e.g. a Kubernetes Vault volume). You can also get external properties dynamically via custom property sources if you really need it. Read your framework documentation folks! There's lots of good stuff you might not know about.

What's your opinion about constants in application?