Skip to content

Updating Factory Implementations for Client generation using Key vault Credentials

harshit aggarwal requested to merge haaggarw/msi-fix into master

All Submissions:

  • [YES] I have added an explanation of what changes in this merge do and why we should include it?
  • [YES] I have updated the documentation accordingly.
  • [YES] I have added tests to cover my changes.
  • [YES] All new and existing tests passed.
  • [YES] My code follows the code style of this project.
  • [YES] I ran lint checks locally prior to submission.

What is the issue or story related to the change?

Currently we are using MSI to connect with Azure Resources in Data Partition, which requires appropriate role assignments of Service Principal and Managed Identities over the respective Azure resources

As of now the DefaultAzureCredential class is getting used to generate AD Tokens for Authenticating to Azure Resources

This change is updating Factory Implementations for Client Generation using KeyVault Credentials

Storage Account Blob Clients & Service Bus Topic Clients are getting initialized using DefaultAzureCredential and corresponding implementation using Keyvault Credentials is introduced in the change

The change is under feature flag and can be controlled via the property azure.msi.isEnabled

  • By default the existing set up of MSI will continue to work as matchIfMissing property is set to true
  • This property has to be set to false to use the clients using KeyVault Credentials
  • Services willing to use clients with KeyVault Credentials should set azure.msi.isEnabled=false in application.properties

The change has been tested by including this version of core-lib-azure in Schema, Storage & WKS service locally

Test coverage:

Does this introduce a breaking change?

  • [NO]

Pending items

Reviewer request

  • Please provide an ETA when you plan to review this MR. Write a comment to decline or provide an ETA.
  • Block the MR if you feel there is less testing or no details in the MR
  • Please cover the following aspects in the MR -- Coding design: <Reviewer1> -- Backward Compatibility: <Reviewer2> -- Feature Logic: <Logic design> -- <Any other context mention here> OR -- <Component 1>: <Reviewer1> -- <CosmosDB>: <Reviewer2> -- <ServiceBus> <Reviewer3> -- <Mention any other component and owner>

Other information

Edited by harshit aggarwal

Merge request reports