GHA Pipeline: Add OIDC support

[jongio]

The command will be something like:

azd pipeline config --auth-type oidc

Please see this implementation to see everything we need to script to get OIDC setup:
https://github.com/jongio/github-azure-oidc/blob/main/oidc.sh

We'll want to include a fics.json file to help the devs understand what they are doing and is a good way to visualize what the FICs look like in JSON format.
https://github.com/jongio/github-azure-oidc/blob/main/fics.json

Here's a video that walks through all the concepts involved with OIDC: https://youtu.be/r5QdsjjdRDs

We have a dependency on the Related: Azure/azure-cli#20582

But we can call the graph REST API directly as I do in the above script until that is implemented.

We will use the azure/login action to support this, so the workflow included with the template will need to be updated to support OIDC or AZURE_CREDENTIALS. We might need to have different workflow files based on the authtype.

[jongio]

Related: Azure/azure-cli#20582

[ellismg]

Just wondering - long term would we want to actually expose the fics.json file? I noticed that most of the documents that talk about OIDC for GitHub end up pushing you though a portal experience where they must construct the fics document on your behalf behind the scenes.

I wonder if we could do something similar long term - maybe start with having folks author their own fics.json and pass it but then move to a world where we do a similar experience (for example, using our survey package we could offer a multi-select of all branches in the target github repository, and you could select which branches you wanted to grant access to).

[jongio]

Yes, fics.json should be dynamic based on what they want to do.

[vhvb1989]

@jongio

• instead of azd workflow create --auth-type oidc , can we use azd pipelline config ?
  I wonder if we can deprecate the current approach and keep only OIDC

• The Json file seems too verbose. There are very little differences between each node.
  azd knows how to get the owner/repo from the project, and the other values are always the same issuer and audiences. If we want to have a config file, we could make it very simple by just listing the type (env, pr, branch or tag).

I would propose splitting this issue into:

1. Move from Azure secret credentials to OIDC for pipeline config using branch=main type by default (so actions runs when pushing
2. Make azd check if there's an input config file, and if yes, use it to create the federated credentials
3. Update azd templates to include the oidc config file and update read me files to tell customers how they can use this file to customize options fro oidc

What do you think?

[jongio]

I updated the command name, that was old.

We'll need to support both types of login until they deprecate non-oidc approach.

OIDC adds a lot more concept counts and potential things to go wrong, so we have to be cautious about going full in on it right now.

[jongio]

Draft supports OIDC, which we can learn from their impl: https://github.com/Azure/draft#commands

The Azure CLI will have better OIDC support in their next release.

Please ping me whomever picks this up.

[ellismg]

This probably impacts the work we want to do for azd login, since azd login will likely have to do something different when using OIDC to authenticate. We'll need to look at how az handles this today.

[jongio]

I investigated the azure/draft OIDC setup-gh command and it is doing the same thing that my oidc.sh script does.

It heavily uses az ad and other az commands.

To implement OIDC in azd we'll need to:

Implement the flow found in my oidc.sh script but using the Azure AD REST APIs directly or Go SDK.

We may also add these features to the Azure ID libs:
https://github.com/Azure/azure-sdk-for-go/tree/main/sdk/azidentity
https://github.com/AzureAD/microsoft-authentication-library-for-go