Improvements to User Secrets

[ElanHasson]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Note: I initially thought this could fit well into aspire, but as I was typing this up, I realized it may be a better fit for dotnet proper. Feel free to move this issue there.

I wish there was a better story around User Secrets for teams or even just new machines.

I got a new computer, cloned my repo, started my project and got an OptionsVaidator exception and it took me a few min to figure out what was missing.

I've invested some time setting up Aspire just right and the project, so it didn't rely on external values for things-- easy to get started day one for new team members: clone repo, F5.

Then I realized it was my User Secrets that were missing-- they're pretty much set and forget-- and they stay on the local machine for obvious reasons.

So, new machine, I have to set them. One more thing to remember to do. One more document to write. One more document to keep in sync. 😢

Describe the solution you'd like

I'd love to see a way to provide a default secrets.json for an Aspire project (or even a csproj as this would benefit non-aspire projects as well).

I do not think we need a new mechanism for this as I think this would fit well into the csproj and this could probably implemented via a MSBuild task.

<Project Sdk="Microsoft.NET.Sdk.Web">
   <PropertyGroup>
   	<!--Exists Today-->
   	<UserSecretsId>37913f03-ffcc-4c77-9904-6b7241929494</UserSecretsId>
   	<!--Proposed-->
   	<UserSecrets>
   		{
   		"clientId": "",
   		"clientSecret": "" // Get creds from https://my-intranet/provision-client,
                       "secret_tokens": []
                       "complexSecrets": {
                          "userId": 43110,
   		}
   	</UserSecrets>
   </PropertyGroup>
</Project>

How would it work?

The point here is not to require a schema be specified, but only structural validation. The assumption is all values are required, values and types aren't validated, the exception is for properties that are object types: we would validate the path exists ($.complexSecrets.userId using above sample).

Non-Aspire

When you open a project in VS or Code, the host would see the UserSecrets element and see the current user secrets specified by UserSecretsId do not match the template specified in the csproj and alert the user that they are required and show them the template.

When you use the CLI, validation would occur at build time and the problem would be surfaced there.

Aspire

I'm not sure what this would look like in aspire, perhaps the above Non-Aspire workflow is better suited to be implemented as a UserSecrets resource that performs the validation.

I think it maybe makes sense to do so as Aspire is responsible for downstream config injection to the projects and user secrets do get injected via a different pipeline outside of Aspire.

Additional context

Related Issues: dotnet/aspire#4035 dotnet/aspire#2953 (comment)

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[Clockwork-Muse]

If these are shared/well-known "local development only" secrets (eg, the password for the Cosmos DB Emulator), you can just put them into the standard development-only properties file, <ProjectFolder>/Properties/launchSettings.json, and just persist them in the repo. These properties are hydrated into the normal config system on debug launch, but aren't published when the application is packaged.

For accessing a shared (probably cloud) resource, in many cases tooling is able to source login credentials from the local user profile (eg, from ~/.azure for those APIs). Written code doesn't explicitly have configuration for a password or other secret, but automatically grabs the user token from there, which is way more ergonomic since it allows for "just using" what would be the managed identity token when deployed (no development vs deploy code changes for user code)

[julealgon]

While I understand where the author is coming from here, I don't think this is a good solution, if only because of how general purpose the IConfiguration system is and the fact that user secrets is just another source for that.

If the problem is that "I lost settings when moving from computer A to computer B", I'd rather have a solution where the secrets were not sourced from the machine, but instead from, say, Azure Key Vault.

It would be nice if it was possible for user secrets to be stored in an instance of KeyVault on Azure and tied to the user's account in Visual Studio, so that they would be downloaded seamlessly as needed and would persist across machines, using the same GUIDs that are used today to identify the projects.

[dotnet-policy-service]

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