Request: Vault Extension Module Path Should be VaultName.SecretManagementExtension

[JustinGrote]

@PaulHigin Great job on the thorough blog posts, it's most helpful.

I think that we should support module authors to be able to have a Secret Management Extension as part of their original module rather than having to spin it off as a separate module, similar to how DSC resources can exist in the same module as the main implementing module. This will reduce the proliferation of modules that have to be downloaded and simplify developers not needing to maintain multiple repositories.

However, the existing VaultName.Extension nomenclature is too vague for this use case. Someone coming across the repository will not know this is specially a implementation of a secret vault, so the path should also support something more specific, such as VaultName.SecretManagementExtension or VaultName.SecretManagementVault or something to clearly denote the code is for the secretmanagement vault extension implementation, since this is hardcoded and not configurable.

Example

For a module named KeePass that implements a vault, the folder structure should allow for KeePass.SecretManagementExtension subfolder, then the user has a very simply starting flow:

Install-Module KeePass #Also gets the regular powershell keepass commands
Register-SecretVault MyKeepass -Module Keepass
#etc...

Recommended Alternative

Consider a new PSData attribute in the psd1 to specify the path or name where the secret vault is located. This would have the additonal benefit to make them far more discoverable, for example something like Get-SecretVault -ListAvailable could search the modules and find which ones have the SecretManagementVault psdata attribute and return a list.

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.92. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[SydneyhSmith]

Thanks @JustinGrote do you know of any other module patterns that use .Extension? We like the idea of having the submodule name in the PSData but arent sure if it is worth making the breaking change for...would love more input from the community on this one--thanks!

[JustinGrote]

@SydneyhSmith not currently so it's not a breaking change but it doesn't hurt to be explicit. The PSData can be an optional addition and SecretManagement can look both places so it wouldn't be breaking to add it.

[PaulHigin]

Changing the required extension vault name would be a breaking change, and all vault authors would have to update their vault modules, and I would prefer not to allow alternative naming conventions as it seems unnecessary. The current naming convention is enough to disambiguate different extension vault modules, and calls to extension vault functions. So I am marking this as 'wont' fix' for now.

[JustinGrote]

@PaulHigin @SydneyhSmith @joeyaiello @SteveL-MSFT my only thought is that there may need to be a wider standard/recommendation on this. For instance, there are now going to be PSReadline intellisense extensions. What's that going to be? If I make a powershell module and I want to implement all of this, am I going to have a bunch of seemingly arbitrary folders in my source to implement them or are they going to have a nice nomenclature, e.g. MyModule.SecretManagementExtension and MyModule.PSReadlineExtension?

[PaulHigin]

I think moving forward the extension directory name can be defined in the parent module manifest, private data field (as suggested by @SteveL-MSFT). Any new extension module can use that and avoid the current SecretManagment hard coded naming convention. In fact, SecretManagement can move to this model at any time and still be backward compatible to the hard coded naming.

But at this time, I don't see any problem with the current naming scheme for SecretManagement.

[JustinGrote]

private data field (as suggested by @SteveL-MSFT)

My original issue above:

😕

[PaulHigin]

Sorry, I forgot you suggested it! But I agree that is a better way to define the extension name.