Open J0F3 opened 1 year ago
Thanks for reporting the issue. @msJinLei Please take a look.
@J0F3 Thanks for reporting the issue. It is caused by the Environment variables set. Azure.Identity selects TokenExchangeManagedIdentity as the MSI source. The Scopes
TokenExchange uses is different from other MSI sources, but share the same interface from TokenRequestContext, which cause the failure.
I also find Azure.Identity has a variable called ExcludeTokenExchangeManagedIdentitySource, which can disable TokenExchangeManagedIdentitySource
. But for current design we are unable to use the property. I create an ask for Azure.Identity https://github.com/Azure/azure-sdk-for-net/issues/37453
CC @dolauli @isra-fel
For WorkloadIdentityCredential
, we don't support yet and will estimate this new feature soon.
@msJinLei Thank you for the update.
For WorkloadIdentityCredential, we don't support yet and will estimate this new feature soon.
Does that mean Azure PowerShell does not support login with Workload Identity at all yet?
We got it working with the -FederatedToken
parameter and explicitly passing the env variables of Workload Identity to PowerShell. (I think it is basically the same as how it works with Azure CLI also) e.g.:
Connect-AzAccount -ServicePrincipal -ApplicationId $env:AZURE_CLIENT_ID -FederatedToken $(Get-Content $env:AZURE_FEDERATED_TOKEN_FILE -raw) -Tenant $env:AZURE_TENANT_ID -Subscription $env:ARM_SUBSCRIPTION_ID
Can we use that when we want to switch to Workload Identity or is it actually not really supported yet to use the -FederatedToken
parameter for login with Workload Identity?
@msJinLei Lei Jin FTE Thank you for the update.
For WorkloadIdentityCredential, we don't support yet and will estimate this new feature soon.
Does that mean Azure PowerShell does not support login with Workload Identity at all yet?
The workaround is to use FederatedToken parameter to login.
We got it working with the
-FederatedToken
parameter and explicitly passing the env variables of Workload Identity to PowerShell. (I think it is basically the same as how it works with Azure CLI also) e.g.:Connect-AzAccount -ServicePrincipal -ApplicationId $env:AZURE_CLIENT_ID -FederatedToken $(Get-Content $env:AZURE_FEDERATED_TOKEN_FILE -raw) -Tenant $env:AZURE_TENANT_ID -Subscription $env:ARM_SUBSCRIPTION_ID
Yes, it's right!
Per my understanding, the implication of WorkloadIdentityCredential is to take advantage of the evn variable directly.
We currently support so-called ClientAssertion
way to login. But you should specify the token and tenant to the parameters by your selves.
https://github.com/Azure/azure-powershell/blob/7407fb00a5c87de5dcc5725a737561049d08a967/src/Accounts/Accounts/Account/ConnectAzureRmAccount.cs#L463
Description
When running
Connect-AzAccount -Identity
on an host where the environment variables for Workload Identity are set (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE and AZURE_AUTHORITY_HOST env variables) the login fails with:ClientAssertionCredential authentication failed: AADSTS70011: The provided request must include a 'scope' input parameter.
It seems that during the login the Workload Identity environment variables are get detected and
Connect-AzAccount
unintentionally try to login with WorkloadIdentityCredential / FederatedToken despite-Identity
ist specified.I think this is a bug. I see two variant how this could be fixed:
Connect-AzAccount
stays with the Managed Identity Login by requesting the Access Token still from the IMDS (aka. http://169.254.169.254/metadata/identity/oauth2/token) despite the existence of the env variables. Which is probably the behavior which one would expect when specifying the-Identity
parameter.Connect-AzAccount
to "https://login.microsoftonline.com/{tenant id}/oauth2/v2.0/token" must be fixed so the login actually works.Issue script & Debug output
Environment data
Module versions
Error output