"Forcing" use of MSI's fetchTokenFromCLI to allow using user's credentials

[leonardotbo]

Hi, I'm working on a use case where we have a shared developer environment and want users to be able to mount the storage accounts that they have access to.

For example, let's say we have Storage Accounts A, B and C.
User X has access to A and B, user Y has access to B and C.
X should be able to mount A and B, but not C. Y should be able to mount B and C, but not A.

The way we had envisioned it is that we would give users access to the Storage Accounts through Entra ID RBAC, and they would be able to use their own credentials to mount the Storage Accounts (think of what you do to SSH into an Azure VM with az ssh vm for example), but we couldn't make it work with the available auth methods (see #1112).

I tried all auth methods, but none seemed to work. The closest we got to it was using az storage account generate-sas, but that has the problem of expiration (too short and it could expire mid-work, too long and it could "out-live" users' RBAC access to the storage account), so we continued searching for another solution.

We use az account get-access-token to connect to services such as databases, so I was thinking of a possibility to integrate that in the source code. Looking at the code, I was able to find a function on component/azstorage/azauthmsi.go called fetchTokenFromCLI which seemed to be exactly what I wanted.

Looking at the places the function is invoked, I saw that it is possible to "force" the use of CLI by setting MSI_ENDPOINT=127.0.0.1:, and it indeed worked! I was able to mount the container without any additional credentials (just by running az login beforehand).

That leads to my suggestion: Is there a way to make this "official"? Instead of setting an env var with an IP, can we maybe add a flag or a mode: login to the config?

If not, is there any risks on doing what we are doing now? How likely is it that this option (using CLI by setting MSI_ENDPOINT=127.0.0.1:) going to be removed in future updates?

Thanks!

[CarstenPacmed]

I'd be very interested in having an --auth-mode login equivalent!

[vibhansa-msft]

As of now we do not support login through "az cli", however thats in our todo list once we migrate to latest of the Go SDK for Azure Storage. May be 6 months down the line this will be available.
For now what you can do is have 2 SPN/Identities created and provide appropriate RBAC to only account (A,B) and (B,C) to those. While mounting for user which has access to (A,B) you use your first identity and for second mount use the second identity. This way they will not have access to other containers.

[CarstenPacmed]

As a workaround, setting MSI_ENDPOINT=127.0.0.1: like @leonardotbo suggests does work right now and uses the user's own credentials to get the access token. Would you advise against using this workaround until you finish the migration to the new SDK? Or is this part relatively stable as a temporary workaround?

[vibhansa-msft]

This feature was introduced to handle situation about login on a "Azure Machine Learning" platform. In that setup you can not get a token from standard AAD endpoint and hence we had to rely on the "az cli" which can look at various env variables to determine where to fetch token from. As you have set this env variable to some value, code is assuming it to be a AML platform and relying on 'az login' command instead. This is a stable feature and you can use it, it's just that its not meant for your environment hence was not suggested.

[leonardotbo]

I see, thanks a lot for the info!

As it is a stable feature, I'd probably use it then :)
One point however, is that I'm facing the error described on #1326.

Also, looking forward to the native implementation of this! Thanks for the great work so far 👍

[leonardotbo]

Hi @vibhansa-msft, I see that there is a preview for version 2.3.0 that one of the features is Migrated from deprecated ADAL to MSAL through the latest [azidentity SDK](https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/azidentity).

I'd like to check with you if:

1. Is there a new "native" way of using a user credentials to mount storage accounts?
2. If there is still no native way, will this refactor break the way that we work now? (by setting MSI_ENDPOINT=127.0.0.1: and using the Azure Machine Learning option)

Thanks!

[vibhansa-msft]

Hi,

There is no breakage in terms of authentication on ML workspaces. For the native way of using user credential part, there is a new authentication mode added with this changeset. Here you can use Azure cli to login and then use blobfuse without providing any authentication details to blobfuse config or cli. Just set the mode as cli and it will automatically take the token from the AzCli itself.

[souravgupta-msft]

Hi @leonardotbo. Please check out the latest release 2.3.0 which has the support for logging using Azure CLI. You will have to set the login mode to azcli in your config file.

[leonardotbo]

Just to give an update, we updated to the latest version and it worked flawlessly. Thanks for your work!