OpenSearch
OpenSearch copied to clipboard
opensearch-project
[Plugins] enable support for Azure Managed Identity in the repository-azure plugin
Is your feature request related to a problem? Please describe
The current implementation of the "repository-azure" plugin in OpenSearch supports authentication to Azure Blob Storage exclusively via a "Shared Access Signature (SAS) Token" or an "Account Key". This approach necessitates developers to manage and maintain these long-lived credentials within their systems, which can be cumbersome and potentially insecure.
I am proposing to enable Azure Managed Identity Support in the "repository-azure" plugin.
Describe the solution you'd like
A viable solution to implement Managed Identity authentication in the repository-azure plugin could be through the use of configuration settings in the "opensearch.yaml" file. This approach would allow developers to switch to Managed Identity authentication as needed, while keeping the current "SAS Token" or "Account Key" methods as the default authentication options
This approach ensures backward compatibility with existing systems while also introducing the flexibility and security benefits of Managed Identity authentication
Related component
Plugins
Describe alternatives you've considered
No response
Additional context
No response
There is a related issue (#9793) which is about workloadIdentity support in the repository-azure plugin.
It is worth to note that, both the ManagedIdentityCredentialBuilder Class and WorkloadIdentityCredentialBuilder Class are different implementation of the TokenCredential Class in com.azure.identity package. They require different parameters when configuring the client to access blob storage, which suggests that their solutions may not be interchangeable.
While there may be some overlap in the processes of implementing support for both Workload Identity and Managed Identity in the plugin, the configuration of the client to access blob storage presents distinct requirements for each. These differences necessitate unique sets of tests, underscoring the complexity involved in each implementation.
Given these considerations, it might be better we treat the implementation of Workload Identity as a separate entity. This approach will allow us to dedicate the necessary attention and resources to each feature, ensuring thorough testing and high-quality results.
Welcome suggestions if others view this differently.
