WIP: Support OIDC in Azure Pipelines

[ellismg]

This change teaches azd how to login using a service connection for
an OIDC like experience when running in Azure Pipelines using service
connections and then updates our pipelines to use this authentication
strategy.

Contributes To #4341

[ellismg]

This is the sample name used in the example on how to get this (liked to via the identity SDK): https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#systemaccesstoken, so I figured I'd use that as a default.

[ellismg]

Instead of storing the value (which is both secret and per build) I figured we'd store the name of the env-var and then look up the value when we needed it. That means we don't need to add anything to the persisted secret struct.

This is used as a bearer token when doing the OIDC dance, internally there's an injected env-var that has a endpoint that the credential make requests to and this token secures these requests.

[ellismg]

@danieljurek I assume the right thing to do here is to pull this off of SubscriptionConfiguration but I don't know enough about what that structure looks like to know if this value there or not. These needs to be the ID of the service connection that we want to use.

The AzureCLI@2 task seems to do name to id translation (I am guessing) but I haven't looked into how that works yet and if we could support it. I found this GUID by looking around at some of our internal configuration files. I won't check this in until you tell me the right way to do it, but trying to get stuff off the ground and taking some shortcuts.

[weikanglim]

This may or may not help:

• AzureCli task that handles the input parameters
• vsts-task-lib that probably has the implementation for retrieving service connections

I think environment variables are being seeded -- I'm not sure if that means you may need an azdo task defined at the pipeline level to get everything working e2e.

[ellismg]

I think environment variables are being seeded

Yes, it looks like this happens when you have a task with an input of type connectedService:AzureRM. So I guess we could make this "just work" in the context of an AzureCLI@2 task (or create our own).

[weshaggard]

Yes see https://github.com/Azure/azure-sdk-for-net/blob/e7d65a13f3f83119ed54e927654e0512d35f087b/sdk/identity/Azure.Identity/samples/OtherCredentialSamples.md#example-of-using-an-azure-pipelines-task

The AzurePipelineCredential pulls the needed variables that get set in the AzureCLi task.

[vhvb1989]

Ideally, I would like to hide all the implementation details from the connection because it is 100% unique to Azure Devops.
Azd currently has the flag --federated-credential-provider to hide all the complexity and implementation of how to do OICD in github actions. That means, when you want to log in azd in in GitHub actions, you do:

run: |
          azd auth login `
            --client-id "$Env:AZURE_CLIENT_ID" `
            --federated-credential-provider "github" `
            --tenant-id "$Env:AZURE_TENANT_ID"

The implementation about how to get the system token and any other tokens is inside azd's implementation.

So, I would like to just have a new provider azdo, which I can use in a Azdo task like:

run: |
          azd auth login `
            --client-id "$Env:AZURE_CLIENT_ID" `
            --federated-credential-provider "azdo" `
            --tenant-id "$Env:AZURE_TENANT_ID"

Azd would internally know what ENV VARS to looks for to get the system access token and the connection-id.
Azd can adapte itself to multiple scenarios. For example, running azd login from the AzureCLI task.

[ellismg]

I can look into this but I think the problem is that without the connection id or service connection name we are not going to be able to make this work. We could consider something like --federated-credential-provider azdo:<service-connection-name> so it would be something like --federated-credential-provider azdo:azure-sdk-tests for us. Maybe we can make that work?

Like you, I'd love to be able to do this.

[weikanglim]

Once we're done with investigation, I'd love to be able to make sense of whether azd should just be an AzDo task to support this scenario better (my hunch was always that it is indeed necessary, without moving mountains in AzDo).

If we are able to deliver an up-to-par experience, I'd love for that to be captured in #4341