vCenter General

Managing VICredentials on PowerShell 7 using VMware.VISecret Module!

Many customers use the PowerCLI credential store to avoid hard coding credentials in scripts or saving them unencrypted in files. The credential store uses the Windows data protection API to encrypt the credentials and then saves them in a file. However, this API is only available in Windows and that’s why the PowerCLI credential store is not available on the cross-platform PowerShell 7. So what is the alternative for Linux and MacOS users?

Some time ago, Microsoft released two very useful cross-platform modules for managing secrets – SecretManagement and SecretStore. You can read more details about them in this blog post. SecretManagement provides cmdlets that help users manage secrets across different vaults and SecretStore is one vault implementation. These two modules can be used instead of the VICredential store. To illustrate how this can be done, we’ve built a sample module with alternative versions of the VICredential store cmdlets using the two Microsoft modules. You can use this module as it is or just as a reference to build your own solution. Let’s go over the main use cases.

Secret store configuration and vault registration

The first step is to register and configure the secret vault. In our sample module, we have added an Initialize-VISecret cmdlet that does this. It registers SecretStore as a default vault and configures it to not prompt for a password when accessing the vault.


This is the mode that is closest to the VICredentialStore as user experience, since it will not prompt for password and will still keep the password encrypted. However, it’s less secure than protecting the vault with a password. In addition, in our sample module we’re using SecretStore as a vault, but if you prefer a different vault you can modify the Initialize-VISecret to use a vault of your choice.

Here are some community vault extensions that are available:

Saving, reading and deleting credentials from the vault

To save credentials to the vault, you should use the Set-Secret cmdlet in the SecretManagement module. The secret in this cmdlet is identified by its name only, but in our case a credential is described by two identifiers – the user name and the server it’s intended for. Therefore, in the New-VISecret cmdlet we’re concatenating “VISecret”, the server and user name by using the pipe symbol as a delimiter, and then we’re using the resulting string as an identifier of the secret. If you want to save credentials for more than one product you could extend the function to replace “VISecret” with another product specific string to build the identifier, for example “VMCSecret” for VMC. You can pass the password as a plain text string or as a secure string.

Similarly, when we read a credential from the vault by using Get-VISecret, it concatenates “VISecret”, the server and username to form the identifier. Then it uses the Get-Secret to retrieve the password for the corresponding server and username.

You can also delete a credential from the store by using Remove-VISecret, which again builds the identifier, and calls Remove-Secret to delete the secret from the vault. If you’re using SecretStore as a vault, you can remove all the credentials it stores by calling Reset-SecretStore

 

Integrated connection experience

The last cmdlet in the sample module is Connect-VIServerWithSecret. It combines the cmdlets above to give you integrated experience, similar to the one that Connect-VIServer provides with VICredentialStore. You can call Connect-VIServerWithSecret with username and password and use the -SaveCredentials parameter to save the credentials in the vault. Then you can call it by passing just the username: Connect-VIServerWithSecret will automatically retrieve the password from the vault and connect you to the vCenter. When you’re using the VICredentialStore, if you only have a single credential saved for a specified server, you could connect with Connect-VIServer without specifying a username. In Get-Secret, however, the -Username parameter is mandatory as we cannot list all saved credentials and check if you only have a single credential saved for the specified server. To enable this experience, we have defined a global variable $global:defaultUser that lets you set a default user name for the Connect-VIServerWithSecret.

Conclusion

By using Microsoft’s SecretManagement and SecretStore modules, you can achieve similar user experience as when you’re using the VICredentialStore. SecretManagement also gives you a rich set of integration options with other third-party vaults, both locally and in the cloud. You can use the sample VISecret module to configure and use vaults in a similar way as with the VICredentialStore.