Azure Devops - enable access to keyvault

0
votes

I'm using the Microsoft Extension to access KeyVaults from Azure DevOps to fetch a secret from the vault. I'm getting this error message which appears to say that I need to allow rights the Azure Devops agent access to the keyvault. "Could not fetch access token for Managed Service Principal. Please configure Managed Service Identity (MSI) for virtual machine 'https://aka.ms/azure-msi-docs'. Status code: 400, status message: Bad Request""

I have this running on a separate test subscription where the AzureDevOps account has contributor access under Role Assignments, same on the PROD subscription where the error message is coming up.

Any insights would be greatly appreciated.

THanks,

1
azurekeyterraformdevops
Are you running this on a self-hosted agent with Managed Identity turned on? If not, you'll probably need to use client id + secret/certificate to access Key Vault from DevOps builds/releases. – juunas
Thanks for the reply. I'm running it on an agent in a Microsoft hosted pool, vs2017-win2016. When I authorized the extension on the subscription that where works it takes the app id from the running DevOps organization. Same thing happens when the extension is configured on the sub where I get the error message at runtime. – mac
Is this question about Terraform? If it is, you should present the Terraform code that is causing you problems. – Alain O'Dea
That is correct, the question is about passing a variable to Terraform but the error is happening before that part. Here is a snippet of the Terraform code used to create the VM using the keyvault secret: resource "azurerm_virtual_machine" "vm" { depends_on = [azurerm_network_interface.vmnic] name = "${var.vmname}" location = "East US" resource_group_name = "RG-DEV-01" ... os_profile { computer_name = "hostname" admin_username = "bdadmin" admin_password = "VMPWD" } – mac

1 Answers

0
votes

This seems to be an issue with Azure keyvaults defined with service endpoints. As Azure DevOps is not a trusted service it does not have access to the endpoint. The workaround is to whitelist the ip of the agent right from the pipeline, removing it after you've obtained the secrets(figuring out how to do this now). This is referenced in here and here