WIP: Support OIDC in Azure Pipelines #4343
Conversation
| @@ -1,6 +1,7 @@ | |||
| parameters: | |||
| SubscriptionConfiguration: $(sub-config-azure-cloud-test-resources) | |||
| AzdDirectory: "" | |||
| ServiceConnectionId: "3d79cc98-46f2-428c-bdd5-861414f85602" | |||
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
The AzurePipelineCredential pulls the needed variables that get set in the AzureCLi task.
ellismg
force-pushed
the
ellismg/support-azure-pipelines-auth
branch
4 times, most recently
from
6d6aec1
to
f22a1ca
Compare
cli/azd/cmd/auth_login.go
Outdated
| @@ -139,6 +141,16 @@ func (lf *loginFlags) Bind(local *pflag.FlagSet, global *internal.GlobalCommandO | |||
| cClientCertificateFlagName, | |||
| "", | |||
| "The path to the client certificate for the service principal to authenticate with.") | |||
| local.StringVar( | |||
| &lf.serviceConnectionID, | |||
| "service-connection-id", | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Made some progress here, we now support using azure-pipelines as an argument to --federated-credential-provider. We now sniff the environment variables that the AzCli and AzurePowerShell tasks set, or if you want to use a different task, you can explicitly set AZURESUBSCRIPTION_SERVICE_CONNECTION_ID.
We may want to end up writing our own wrapper task at some point.
There was a problem hiding this comment.
I started an azd task for azdo some time ago. Basically copying what the AzureCLI task does here: https://github.com/microsoft/azure-pipelines-tasks/tree/master/Tasks/AzureCLIV2
I stopped myself and started wondering if we want to update AzureCLIV2 to check if azd is installed and login azd as well as az. It would be one less task to install for customers.
ellismg
force-pushed
the
ellismg/support-azure-pipelines-auth
branch
from
f22a1ca
to
0a257b5
Compare
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 Azure#4341
ellismg
force-pushed
the
ellismg/support-azure-pipelines-auth
branch
from
0a257b5
to
2ee5a78
Compare
jongio
changed the title
ellismg
force-pushed
the
ellismg/support-azure-pipelines-auth
branch
2 times, most recently
from
cd2961b
to
5a7e72d
Compare
ellismg
force-pushed
the
ellismg/support-azure-pipelines-auth
branch
from
5a7e72d
to
f1d9cdc
Compare
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
This reverts commit b3e3568.
This change teaches
azdhow to login using a service connection foran OIDC like experience when running in Azure Pipelines using service
connections and then updates our pipelines to use this authentication
strategy.
Contributes To #4341