The gMSA PowerShell module creates an improperly formatted key vault secret.

[spowell-kcc]

Please fill out all the sections below for bug issues, otherwise it'll be closed as it won't be actionable for us to address.

Describe the bug One of the Authors of this module asked me to report this bug here.

The gMSA PowerShell module function New-GMSAAzureKeyVault doesn't create a properly formatted key vault secret for the account used to manage the gMSA account.

Using the secret created by the function results in the following errors when a gMSA credSpec container is launched:

• Failed to setup the external credentials.
• The RPC server is unavailable. (0xC0020017)

To Reproduce Call the New-GMSAAzureKeyVault function with the expected parameters.

A key vault secret will be created with the following value: "value": "System.Security.SecureString"

Expected behavior The key vault value should be created as one of these values:

• "value": "<fqdn.com>\<username>:System.Security.SecureString"
• "value": "<fqdn.com>\<username>:<password-in-plain-text>"

Configuration:

• AKS version 1.27.9
• gMSA Module Version: 1.4.2

Additional context

Line 839 in the PowerShell module sets the secret value as this:

$secretValue = ConvertTo-SecureString -String "${GMSADomainUser}:$([System.Net.NetworkCredential]::new('', $GMSADomainUserPassword).Password)" -AsPlainText -Force

... fully encoding the domain, username and password.

The key vault configuration section of the Enable Group Managed Service Accounts (GMSA) for your Windows Server nodes on your AKS | Microsoft Learn uses this example:

az keyvault secret set --vault-name myGMSAVault --name "GMSADomainUserCred" --value "$Domain\\$DomainUsername:$DomainUserPassword"

... setting the password as plain text.

Converting the secret string to encode only the password as a secure string, or to set the password as plain-text only, eliminates the errors and allows the AKS gMSA plugin to launch the containers using the desired gMSA user context.