Open KarishmaGhiya opened 2 months ago
Thank you for your feedback. Tagging and routing to the team member best able to assist.
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 ...
@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
@mjsabby what is your task scenario? Can you elaborate on what pipeline task you're using and how you want to use it?
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
@kkazala thanks. Your post uses PowerShell (to connect to SharePoint). How would you intend to use DefaultCredential
or AzurePipelinesCredential
?