Managing certificates in a hybrid cloud environment can be complex, but Azure Arc-enabled servers simplify this process. By using the Azure Key Vault extension, you can securely acquire and manage certificates. Here’s a quick step-by-step guide:
Prerequisites
Ensure you have the following:
- An Azure subscription.
- An Azure Key Vault with the necessary permissions (detailed below).
- Azure Arc-enabled Windows servers.
- Azure PowerShell module installed.
Permissions
Each Arc-enabled server comes with a system-assigned managed identity. This identity is used by the Azure Key Vault extension to authenticate with your vault and retrieve certificates. To function properly, each Arc-enabled server requires GET and LIST permissions on the secrets in your Key Vault. The Key Vault Certificate User RBAC role is ideal for this purpose, adhering to the principle of least privilege.
For larger deployments, it’s advisable to group your Arc-enabled server identities into an Microsoft Entra security group and grant this group access to the vault.
Step 1: Log in to Azure
Log in to your Azure account using the Azure PowerShell module:
Connect-AzAccount
Step 2: Define the Settings
First, define the settings for secrets management and authentication. This includes specifying the Key Vault URL, certificate store location, and polling interval.
$Settings = @{
secretsManagementSettings = @{
observedCertificates = @(
"https://MYKEYVAULT.vault.azure.net/secrets/MYCERTIFICATE"
# Add more here in a comma separated list
)
certificateStoreLocation = "LocalMachine"
certificateStoreName = "My"
pollingIntervalInS = "3600" # every hour
}
authenticationSettings = @{
# Don't change this line, it's required for Arc enabled servers
msiEndpoint = "http://localhost:40342/metadata/identity"
}
}
At line number 4, adjust the certificate URI by changing the Key Vault name (mykeyvault in the example above) followed by the certificate name (myAzureCertificate in the example above). If you want to configure more certificates, you can add them from the same Key Vault or from different Key Vaults, using a comma-separated list format.
Polling is also an important setting because it controls the behavior of the extension, determining how frequently it will check for new versions of the configured certificates. This ensures that your server always has the most up-to-date certificates, enhancing security and compliance.
Lastly, adjust line number 7, by specifying the certificate store in which the Certificate will reside to. In the example above the certificate will be stored under LocalMachine/My.
Step 3: Set Resource Variables
Next, set the variables for your resource group where the Arc-enabled machine is contained, specify the Arc-enabled machine name, and lastly, the location.
$ResourceGroup = "myrg"
$ArcMachineName = "myarcsrv01"
$Location = "westeurope"
Step 4: Install the Key Vault Extension
Use the New-AzConnectedMachineExtension cmdlet to install the Key Vault extension on your Arc-enabled server.
Important Note: If the cmdlet is not recognized, install the AzConnectedMachine module by typing:
Install-Module -Name Az.ConnectedMachine
New-AzConnectedMachineExtension -ResourceGroupName $ResourceGroup -MachineName $ArcMachineName -Name "KeyVaultForWindows" -Location $Location -Publisher "Microsoft.Azure.KeyVault" -ExtensionType "KeyVaultForWindows" -Setting $Settings
This command installs the Key Vault extension and configures it with the settings defined earlier.
A few minutes after the extension is installed, check the certificate store, and you should see that the Arc-enabled server has successfully acquired the certificate!
On a side Note
If you prefer an easier path of implementing this, please note that the Key Vault extension cannot be deployed through the Azure Portal.
There is no way to install the extension at scale using a built-in Azure Policy. At the moment, scripting is the only way around.
There is a well-written Azure Arc Jumpstart Scenario for Key Vault Integration with Linux here Azure Arc Jumpstart.
Microsoft IIS and Key Vault Integration offer a competitive advantage, in which every time you update certificates in Key Vault, the certificate is automatically installed in IIS. This IIS capability is called Certificate Rebinding. Learn more about it here: Certificate Rebind in IIS 8.5 | Microsoft Learn.
Bonus
If you want to try out this capability without having an actual certificate from a Certification Authority, Azure provides the option to create a self-signed certificate. Here’s an example of how to create one and store it in a Key Vault. Remember to assign yourself the required permissions on the Key Vault first; otherwise, the operation will fail.
# Log in to Azure
Connect-AzAccount
# Create a self-signed certificate and store it in Key Vault
$certName = "MySelfSignedCert"
$keyVaultName = "mykeyvault"
# Create the self-signed certificate
$Policy = New-AzKeyVaultCertificatePolicy -SecretContentType "application/x-pkcs12" -SubjectName "CN=contoso.com" -IssuerName "Self" -ValidityInMonths 12 -ReuseKeyOnRenewal
# Import the certificate to Key Vault
Add-AzKeyVaultCertificate -VaultName $keyVaultName -Name $certName -CertificatePolicy $Policy
Conclusion
By following these steps, you can easily manage and acquire certificates from Azure Key Vault on your Arc-enabled Windows servers. This not only ensures your applications remain secure and compliant but also streamlines the lifecycle management of certificates, making it easier to handle renewals and updates.
Feel free to reach out if you have any questions or need further assistance.
Happy managing!
What bothers me is that role “Key Vault Certificate User” has to be granted on the KeyVault level, not on the certificate level. This way all ARC machines will be able to get all others certificates which doesn’t make sense. Or you have to create per machine keyvault which is shitty solution too