Authorize GitHub Workflow to publish to ACR and deploy to cluster

[qpetraroia]

The AKS extension allows users to create workflow files that publish images to an ACR and deploy applications to a cluster. There is also a command to 'attach' the ACR to the cluster, giving the kubelet identity AcrPull permission on the ACR. However, a few extra pieces need to be set up to authorize the GitHub workflow to run successfully, namely:

• An Entra ID application needs to be created, with federated credentials configured to allow the workflow to use it.
• Secrets (for tenant, Entra ID application and subscription) need to be stored in the GitHub repo.
• Role assignments need to be added for the application's Service Principal, to allow it to publish to the ACR and deploy to the cluster.

Both Automated Deployments and Draft are able to set up this configuration. However, with both these tools, there is very little visibility into what secrets, applications, identities, credentials and role assignments are being created. This is not ideal from a UX perspective (it can feel opaque and magic, without helping users understand what they've done). It is also potentially worrying from a security standpoint, because if you're not even aware of the resources you've created it's impossible to review and clean them up.

In our implementation, we can provide a much more interactive experience, allowing users to select existing applications and service principals, and review their role assignments, federated identity credentials and associated GitHub secrets. Missing secrets, credentials or role assignments can be added, and extraneous ones removed.

[peterbom]

I can see a couple of approaches for authenticating the Azure user account with GitHub: via the DevHub API, or directly through VS Code.

DevHub API

To consume the DevHub API, we add a dependency to @azure/arm-devhub, which gives us a JS Client that we can use to call gitHubOAuth. If the user has previously authorized the 'AKS Developer Hub' oauth application to access their GitHub account (see screenshot), this will return a token allowing the user to interact with the GitHub API as this application.

However, if the user is attempting to authenticate for the first time, gitHubOAuth does not return a token. It just returns a URL that can be used to initiate an oauth flow in which the user can grant the AKS Developer Hub application permission to access their GitHub account. It's not clear to me if/how we would handle the callbacks required to complete this flow. It might be achievable by building a custom authentication provider.

Through VS Code

The VS Code API has a built-in getSession function which can be used to achieve almost the same result. It retrieves a token for an oauth application (called 'GitHub for VS Code', see screenshot) that has been registered with GitHub, and can also initiate an interactive flow to allow the user to authorize the application in the first place.

Which approach to use?

Consuming the DevHub API would maximise code reuse since we'd be making use of an existing RP, and might even mean we wouldn't depend on the Draft binary. It would also mean that authorization performed in the Portal would also take effect in VS Code, and vice versa.

However, that would make us entirely dependent on the RP implementation and would make it harder to innovate independently. If we were simply building "Automated Deployments for VS Code", this is probably what we'd want, but we are really building our own experience, which we don't want to be tied to a specific Portal feature.

So, in terms of both development effort and agility I think it'd be preferable to use the built-in VS Code API for GitHub authorization.