Azure / azure-sdk-for-net

This repository is for active development of the Azure SDK for .NET. For consumers of the SDK we recommend visiting our public developer docs at https://learn.microsoft.com/dotnet/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-net.
MIT License
5.26k stars 4.6k forks source link

[Identity] AzurePipelinesCredential parameterless constructor and add to DAC #44969

Open KarishmaGhiya opened 2 months ago

KarishmaGhiya commented 2 months ago
github-actions[bot] commented 2 months ago

Thank you for your feedback. Tagging and routing to the team member best able to assist.

mjsabby commented 2 weeks ago

Is there an update here?

tenantId, clientId, serviceConnectionId are the current parameters that seem required. systemAccessToken has a well-known environment variable SYSTEM_ACCESSTOKEN.

AZURE_TENANT_ID and AZURE_CLIENT_ID already have precedent in EnvironmentCredential so they could be used for tenantId and clientId.

This leaves serviceConnectionId. I'm imagining this is the only real creative writing excercise this is blocked on? Should we pick an environment variable name and call it a day?

Developers who want their code to look the same in all compute where their code run on are really hurting for this being added to DefaultAzureCredential.

Unless I'm missing something, my thought would be to pick a name and call it a day ...

scottaddie commented 1 week ago

@mjsabby We're working with the Azure Pipelines team to get this work prioritized. Unfortunately, it didn't make the cut for the current quarter. They're reconsidering the work for next quarter. /cc: @geekzter

geekzter commented 6 days ago

@mjsabby what is your task scenario? Can you elaborate on what pipeline task you're using and how you want to use it?

kkazala commented 4 days ago

I'll chime in. I'm using Azure DevOps pipelines with pipeline's workload identity federation to deploy non-azure resources with a script running in AzurePowerShell@5 task. All Microsoft cloud resources are secured with Entra ID; which means that as long as I grant Service Principal permissions to the target environment (be it SPO or Power Platform, etc) I can deploy resources without going through authentication with secrets/passwords

I described it here: Azure DevOps Pipeline: no secrets, no certificates

geekzter commented 4 days ago

@kkazala thanks. Your post uses PowerShell (to connect to SharePoint). How would you intend to use DefaultCredential or AzurePipelinesCredential?