Fun fact- this video was recorded while I was in prodromal labor, and although you can’t tell- I was in a lot of pain. I recorded this video with Barry at the Öredev conference after my session on ASP.NET Core, and afterwards we drove home. The next day I had to make an emergency visit to the hospital, and a week later Loke was born.
Barry did a session on ASP.NET Core Security at Öredev, a really good session you should watch! It was intense and dense, no time wasted. Highly recommended! During his session he talked about configuration files, which you can use in ASP.NET Core apps, vs using environment variables.
In our system we do a mixed approach, we have a service that gets configuration settings by first checking for environment variables, if none are set for that setting it looks in the config files (when built locally it uses a local config file to inject local settings). The config files never have any environment specific settings set, these are added at build time and not checked in to source control. When we deploy, we inject the settings from a vault, and the sections are encrypted. ASP.NET Core has something called the Secret Manager which stores local secrets and passwords. App secrets are stored in a separate location from the project tree, and these are not encrypted- and therefore only recommended for development purposes. The Secret Manager works similar to the way we (at Konstrukt) inject local settings on the fly.
(Stored here: %APPDATA%\Microsoft\UserSecrets\
Is it better to use configuration files instead of environment variables?
Short answer: secrets and passwords should be environment variables, as it’s easy to accidentally share those when checking in source code, or even when deploying.
For more details watch the video where we talk about the various ways to handle sensitive configuration data, for example using environment variables, injecting configuration values and more.