Extension for "dotnet user-secrets" in PowerShell Secrets Management

[markm77]

Hi there,

I'm really liking the look of the new secrets management module.

A question - do you plan to support the secrets.json file currently managed by the dotnet user-secrets tool for local secrets used by an ASP.NET Core app?

The reason I ask is I'd like to create PowerShell scripts that interact with secrets for an ASP.NET Core app and target either the secrets.json file (for local dev) or an Azure vault (e.g. for test/prod) depending on the vault choice. Having an extension for secrets.json secrets would obviously save me a lot of if/else clauses everywhere.

Ultimately I'd rather use the PowerShell local vault instead of secrets.json for dev work (more secure) but that would require a C# Secrets Management API which is probably some time away.

BR, Mark

[JustinGrote]

I mean there's no reason it can't be created as a vault extension, I don't think there's anything specifically in this repository that would need to be required.

I'm not aware of any announced plans for specific key vaults, though the Azure Key Vault team has created one, I've created a proof of concept for KeePass, etc.

[markm77]

For info I just submitted an issue for ASP.NET Core to support local secrets created by PowerShell Secrets Management: https://github.com/dotnet/aspnetcore/issues/21287. This for me would be in fact a better solution than a new extension but a new extension would be better than nothing. 😊

[JustinGrote]

@markm77 ah I see what you are saying, yeah that would have to be owned by that team, and having them in secrets rather than the plaintext secrets.json would be ideal. Doesn't ASP.NET let setting environment variables for secrets.json secrets? Maybe this could tie into that to at least have them be ephemeral in memory rather than hard coded, or you could have as part of your process having secrets management temporarily write the secrets.json and then delete it after running is complete.

Just some ideas.

[markm77]

HI @JustinGrote , thanks for this, appreciated. While local secrets via PowerShell would be more secure actually since secrets.json is only really for local debug that's not the biggest reason for requesting this change. The biggest reason is to have a single interface for managing and creating both local and remote secrets and the ability to write scripts that are common to both cases. Which in fact is I believe basically the entire purpose of the Secrets Management project 😊