Refactor Azure authentication support to use azidentity

[akashsinghal]

What would you like to be added?

Ratify's Azure Key Vault and ORAS workload identity provider utilize azure/go-autorest library for fetching the AAD token. This library is now deprecated as of March of 2023. Ratify should transition to use azidentity go package which the ORAS Managed Identity auth provider already uses.

Furthermore, Ratify should take the time to support a more generic AAD auth token fetch functionality that can accept a configurable DefaultAzureCredential which can support environment, workload identity, managed identity, and interactive authentication. Along with this, the AKV provider and ORAS auth provider should provide more generic azure support to handle mutiple flows of authentication, not just Workload identity. This is critical for CLI scenarios.

Anything else you would like to add?

No response

Are you willing to submit PRs to contribute to this feature?

• Yes, I am willing to implement it.

[akashsinghal]

Required for #1300

[duffney]

New packages are available for certificates and keys from AKV as well:

• https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azkeys
• https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azcertificates

[akashsinghal]

This work for azidentity migration may also require rethinking how our current auth provider/akv authentication works. Right now we use the deprecated azure/go-autorest only for token exchange of JWT Workload identity token for AAD token. The ORAS auth provider and AKV provider then use separate auth functionality to use AAD token. The new azidentity doesn't require manual workload identity-specific operations to be specificed. Instead it works by specifying the credential type (e.g. az cli, workload identity, environment, managed identity) and the SDK itself handles functionality. The return value is the AAD token directly. Ideally, we should design a solution that can leverage multiple credential types and not just workload identity (the DefaultCredential is a good option).

[binbin-li]

I did some investigation, post my findings:

1. We don't have direct dependency on github.com/Azure/go-autorest/autorest/azure/auth, and we can remove the dependency on github.com/Azure/go-autorest/autorest/adal by removing this unused line: https://github.com/ratify-project/ratify/blob/dev/pkg/keymanagementprovider/azurekeyvault/auth.go#L67
2. For fetching AAD token, we are using the library: github.com/AzureAD/microsoft-authentication-library-for-go. Though it's not deprecated yet, but just as @akashsinghal mentioned, the azidentity library could provide an easier way to consolidate auth workflow across different approaches.
3. The DefaultAzureCredential is an ideal option if we don't have additional configuration besides default setup. Otherwise we can use ChainedTokenCredential instead.
4. From the example provided by AKV sdk, it's also quite straightforward to create KV client with DefaultAzureCredential.

[duffney]

@shahramk64 just curious if you've made any progress of this just yet. I'm working on a related issue #1751 and will likely update the certs packages.

[shahramk64]

@duffney I haven't started working on this one yet. I'll update you once this one is started.