在Azure DevOps构建管道中使用托管身份 [英] Use managed identities in Azure DevOps build pipeline

问题描述

我设法使以下代码正常工作(

发布配置文件是特定于Azure App Service的身份验证机制，可让您通过Kudu进行发布.

管理身份标签有误.它们用于允许运行Azure管道的VM充当该VM的托管身份(然后，您可以将此托管身份访问权限授予希望其能够在Azure Portal中访问的资源).这比其他身份验证方法的工作方式有些倒退，但是我想当您在Azure中的VM上托管自己的Azure管道时，这是有道理的.此选项有此警告.

AzureServiceTokenProvider 仅可在公开 MSI_ENDPOINT (又称为 IDENTITY_ENDPOINT )的环境中使用.托管的Azure DevOps管道不是这样的环境.

您很可能会使用服务主体.

服务主体有自动和手动两种.再次贴错标签.实际上，使用自动选项没有任何自动选项，唯一发生的是，它为您提供了Azure AD中的服务主体.它将在订阅级别向服务主体授予贡献者角色(这意味着对访问订阅中除访问控制之外的所有内容的完全访问权限).您不应授予服务主体这种访问权限.太过分了.请记住，您的服务主体仅受凭证保护，如果凭证泄漏，则任何人都可能遭受无法弥补的伤害.

I managed to get the below code to work (complete code here) to use Azure managed identity to authenticate (via Visual Studio) and have access to Azure storage account without using credentials.

const string storageResource = "https://storage.azure.com/";

var authResult = await azureServiceTokenProvider.GetAuthenticationResultAsync(storageResource, cancellationToken: cancellationToken);

The code managed to find my user logged in to Visual Studio and uses it to get the token and all goes well.

However, this code is executed as part of a library integration tests in an Azure DevOps build pipeline.

I found the service principal created when I created the service connection to Azure in Azure DevOps and gave it the same Storage Blob Data Contributor role hoping that Azure DevOps would use it to run the code but had no success.

So my question is:

How do I get code that runs in Azure DevOps build pipeline to be able to authenticate using the AzureServiceTokenProvider?

BTW, the error message:

Microsoft.Azure.Services.AppAuthentication.AzureServiceTokenProviderException : Parameters: Connection String: [No connection string specified], Resource: https://storage.azure.com/, Authority: . Exception Message: Tried the following 3 methods to get an access token, but none of them worked. Parameters: Connection String: [No connection string specified], Resource: https://storage.azure.com/, Authority: . Exception Message: Tried to get token using Managed Service Identity. Access token could not be acquired. Failed after 5 retries. MSI ResponseCode: BadRequest, Response: {"error":"invalid_request","error_description":"Identity not found"} Parameters: Connection String: [No connection string specified], Resource: https://storage.azure.com/, Authority: . Exception Message: Tried to get token using Visual Studio. Access token could not be acquired. Visual Studio Token provider file not found at "C:\Users\VssAdministrator\AppData\Local.IdentityService\AzureServiceAuth\tokenprovider.json" Parameters: Connection String: [No connection string specified], Resource: https://storage.azure.com/, Authority: . Exception Message: Tried to get token using Azure CLI. Access token could not be acquired. ERROR: Please run 'az login' to setup account.

TearDown : System.NullReferenceException : Object reference not set to an instance of an object.

解决方案

When you create a service connection in Azure DevOps you are presented with (as of writing) 4 options.

• Service principal (aka app registrations in your Azure Active Directory)
• Manage identity
• Publish Profile

A publish profile is an Azure App Service specific authentication mechanism that lets you publish via Kudu.

Manage identities are somewhat mislabeled. They are used to allow a VM running your Azure pipelines to act as the managed identity of that VM (you then give this managed identity access to the resources you want it to be able to access in the Azure Portal). This is somewhat backwards from how the other authentication methods work but I guess it makes sense when you are hosting your own Azure pipelines on VMs in Azure. This option has this caveat.

The AzureServiceTokenProvider will only work from within an environment that expose the MSI_ENDPOINT (aka IDENTITY_ENDPOINT). Hosted Azure DevOps pipelines are not such environments.

Service principals is what you will be using in all likelihood.

Service principals come in two flavours automatic and manual. Again with the mislabeling. There's actually nothing automatic with the automatic option the only thing that happens is that it provisions the service principal in your Azure AD for you. It will grant the service principal the contributor role at the subscription level (which means full access to everything in the subscription except access control). You should not grant service principals that kind of access. It is excessive. Remember that you service principals are just protected by credentials, that if they leak, allow anyone to do irreparable harm.

这篇关于在Azure DevOps构建管道中使用托管身份的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！