.Net Core comes with a Secret Management tool to store secrets for development purposes. If I have understood documentation correctly, so there is no encryption involved and all is stored in plain text.
Now the question is, why would we use this relatively cumbersome approach if we can just read from appsettings.secrets.json files e.g. that is much easier to work with and see secrets and add it to .gitignore so that it never appears in the source control.
Are there any security problems that I have not thought about with using this easier approach?
P.S. I can only think of a danger with accidentally commiting secrets file, but it's not that easy unless you change your whole .gitignore file
I think I should put the comments in a single answer.
The primary concern is that sensitive data shouldn't use the same distribution channels as the code. That's why .gitignore isn't enough. You'd be using the very same channel and depend on correct handling of a .gitignore file that any user can modify. The possibility of a mistake will always be there.
Whether that's acceptable depends on the type of secrets. How sensitive is that data? If it contains the sa or sys password for the development database, well don't use that account. Use a separate account with limited privileges, that's only meant to access that database. Losing the password to a limited dev account probably isn't a big concern. Probably.
On the other hand, if it contains API or account keys to your cloud dev/staging environment, oops. It may be a staging environment but someone could still use them to do start VMs, create accounts or steal data.
The big advantage of the secrets tool is that it works inside the configuration architecture. To the application, it appears as just another config provider that can be used or not depending on eg an environment variable or command-line option.
It's not the only option either, just a convenient way of handling secrets, especially in a distributed or OSS development environment. There are other options too:
In a corporate environment you could put a "secrets" file in a file share where only the team members have read access and share the location through another configuration provider, eg through environment variables. The file can be secured through a security group which means adding/removing access to it will be a lot easier than adding/removing access to individual files. You could enable auditing on the file share to see who accesses the secrets file too. That's something you can't do with .gitignore
You could use the environment variables to pick different paths per environment (development, qa, build server etc).
You could even use a database that returns different secrets to different roles/environments. A Key management system can be seen as a cryptographically secured settings database after all.
You could also replicate some settings files. You could do that with etcd on Linux or file replication on Windows. That's one way of delivering settings changes to multiple servers/containers too.