dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.29k stars 4.74k forks source link

[API Proposal]: Ensure configuration secrets come from appropriate provider (e.g. key secret provider) #66448

Open markm77 opened 2 years ago

markm77 commented 2 years ago

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 shared appsettings.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

ghost commented 2 years ago

Tagging subscribers to this area: @dotnet/area-extensions-configuration See info in area-owners.md if you want to be subscribed.

Issue Details
### 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 shared `appsettings.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_
Author: markm77
Assignees: -
Labels: `api-suggestion`, `untriaged`, `area-Extensions-Configuration`
Milestone: -