Open markm77 opened 2 years ago
Tagging subscribers to this area: @dotnet/area-extensions-configuration See info in area-owners.md if you want to be subscribed.
Author: | markm77 |
---|---|
Assignees: | - |
Labels: | `api-suggestion`, `untriaged`, `area-Extensions-Configuration` |
Milestone: | - |
Background and motivation
I am using the ASP.NET Core options pattern for configuration in an open-source library/web app product.
Some options classes contain very sensitive configuration (e.g. private keys) which should not be provided by
appsettings.json
files but only key secrets providers or environment variables (depends on customer production environment). On the other hand, it is fine for things like logging levels to be configured via sharedappsettings.json
files.Is it possible to have e.g. a class or property-level attribute that allows an option to be only populated from secure/selected providers?
This would help ensure users don't add sensitive key secrets to
appsettings.json
files in the repo!! (And, for example, accidentally push them into the public domain.) It would provide a safeguard to aid better security practice.API Proposal
Suggest a new attribute on options classes or their properties but there may be a better way. The new attribute would specify a subset of valid configuration providers for that option (e.g. blacklist or whitelist or filter).
API Usage
Individual options or options classes could be tagged to use a subset of configuration providers when setting values.
Alternative Designs
No response
Risks
No response