Feature request: Support for `DefaultAzureCredential`-backed authentication method

[headcr4sh]

Description

I would like to simplify the configuration of jgroups in my current setup where I run my workload on Azure Container Apps. I have assigned my Container App instance all the necessary IAM permissions to interact with the blob storage that I want to utilize and therefore don't want to specify storage_access_key, which is

1. unnecessary
2. possibly unsafe, because it's a "shared secret" that I need to distribute and rotate

Suggestion

• a. Make the parameter storage_access_key optional
• b. If the parameter has not been set, use DefaultAzureCredential to authenticate/authorize the blob storage client

Side effects

Utilizing the AzureDefaultCredential offers some other benefits as well, because the full chain of posssible mechanisms to obtain credentials (6 steps as of writing this ticket) will be utilized, which is the standard way when working in/with Azure.

[rhusar]

You are absolutely right @headcr4sh, this needs to be done, just nobody got around to it yet, so thank you for raising this.

If I submit the changes, would you be able to test and verify the changes?

[headcr4sh]

You are absolutely right @headcr4sh, this needs to be done, just nobody got around to it yet, so thank you for raising this.

If I submit the changes, would you be able to test and verify the changes?

Hi @rhusar,
thanks for the quick reply.

I am just tinkering around with your sources and about to provide a patch for what I would like to see. Hopefully, I can provide a Pull Request (which will then of course have been tested in my Azure environment) for you, which you might incorporate. It's been a while since I wrote some Java code, so you'll better double-check what I come up with, though...

[rhusar]

You are absolutely right @headcr4sh, this needs to be done, just nobody got around to it yet, so thank you for raising this.
If I submit the changes, would you be able to test and verify the changes?

Hi @rhusar, thanks for the quick reply.

I am just tinkering around with your sources and about to provide a patch for what I would like to see. Hopefully, I can provide a Pull Request (which will then of course have been tested in my Azure environment) for you, which you might incorporate. It's been a while since I wrote some Java code, so you'll better double-check what I come up with, though...

OK great, that's even better. I might have an old unfinished branch for this somewhere too, I ll have a look.

[headcr4sh]

@rhusar

Unfortunately, the PR became a lot more complex than intended.
Not quite sure if that's something you want to go with...

[rhusar]

@rhusar

Unfortunately, the PR became a lot more complex than intended. Not quite sure if that's something you want to go with...

I see the change includes changes to the SDK which was also on the list, so two birds with one stone. Unfortunately that makes it harder to see in SCM what changes are version bump and which are supporting proper credentials, but we can manage.

What software are you using this in? Any chance you using this in WildFly? Because that will needs changes when integrated to it.

[headcr4sh]

What software are you using this in? Any chance you using this in WildFly? Because that will needs changes when integrated to it.

I am working on the deployment of Keycloak in a containerized environment using Container images from Bitnami and figured out that this jgroups module might be a good solution to configure the distributed caching mechanism.

Thus: I think the software is running on an embedded version of WildFly under the hood ... ?

[J0F3]

I would be very interested in this too (for running Keycloak in Azure Container Apps). Currently I am passing the Storage Account Key trough the JAVA_OPTS_APPEND env variable. But this is actually quite insecure and would love when we cloud get rid of the Access Key and can use the Azure credentials instead.

So, any news on this? 🙂

[rhusar]

I would be very interested in this too (for running Keycloak in Azure Container Apps). Currently I am passing the Storage Account Key trough the JAVA_OPTS_APPEND env variable. But this is actually quite insecure and would love when we cloud get rid of the Access Key and can use the Azure credentials instead.

So, any news on this? 🙂

Thanks for the ping, yeah agreed, this needs to happen. I will try to resume this next week.