az feedbackauto-generates most of the information requested below, as of CLI version 2.0.72
Describe the bug
A clear and concise description of what the bug is.
az ad signed-in-user show crashes if signed in using Service Principal
az ad signed-in-user show --query objectId --output tsv
Resource not found for the segment 'me'.
To Reproduce
Steps to reproduce the behavior.
az login --service-principal -u ${AZURE_CLIENT_ID} -p ${AZURE_CLIENT_SECRET} --tenant ${AZURE_TENANT_ID} && az account set -s ${AZURE_SUBSCRIPTION_ID}
az ad signed-in-user show
Expected behavior
A clear and concise description of what you expected to happen.
Command behaves same way for SP and User signed in
Environment summary
Install Method (e.g. pip, interactive script, apt-get, Docker, MSI, edge build) / CLI version (az --version) / OS version / Shell Type (e.g. bash, cmd.exe, Bash on Windows)
MSI
Additional context
Add any other context about the problem here.
Azure CLI internally uses Python SDK to call AAD Graph REST API "Get the signed-in user".
get.metadata = {'url': '/{tenantID}/me'}
https://docs.microsoft.com/en-us/previous-versions/azure/ad/graph/api/signed-in-user-operations#get-the-signed-in-user--
This API only supports user's token. For Service Principal, you may use az account show to get the Service Principal name, then use az ad show to query the detailed information: https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest#az-ad-sp-show
@jiasli yeah, it makes sense.
However, if you use az cli in a script, it means each user has to implement their own forks for SP/user again and again in some cases. It would be great if az cli can adapt based on the current authentication since it already has all required data and knows the auth mechanism.
Thank you for the feedback. We will consider this as a feature request.
@jiasli is there any update on this? We have the pod managed identity integrated but from the current cli implementation, there's no way for us to verify the identity form cli for the pod..., it's kind of doesn't really make sense ...
this is what CLI shows me when I wanted to verify who I am from a pod with has managed identity binded
bash-5.0# az account show
{
"environmentName": "AzureCloud",
"homeTenantId": "$TENANTID",
"id": "$SUBID",
"isDefault": true,
"managedByTenants": [],
"name": "$SUBNAME",
"state": "Enabled",
"tenantId": "$TENANTID",
"user": {
"assignedIdentityInfo": "MSI",
"name": "systemAssignedIdentity",
"type": "servicePrincipal"
}
}
This information doesn't really tell me anything so it's hard for us to automatically check the permissions
add to S168
@jiasli is there any update on this? We have the pod managed identity integrated but from the current cli implementation, there's no way for us to verify the identity form cli for the pod..., it's kind of doesn't really make sense ...
this is what CLI shows me when I wanted to verify
who I amfrom a pod with has managed identity bindedbash-5.0# az account show { "environmentName": "AzureCloud", "homeTenantId": "$TENANTID", "id": "$SUBID", "isDefault": true, "managedByTenants": [], "name": "$SUBNAME", "state": "Enabled", "tenantId": "$TENANTID", "user": { "assignedIdentityInfo": "MSI", "name": "systemAssignedIdentity", "type": "servicePrincipal" } }``` This information doesn't really tell me anything so it's hard for us to automatically check the permissions
@qianwens, I think this is a really good argument to include all of objectId, clientId and resourceId so that users can know who the managed identity is. I already parsed them in https://github.com/Azure/azure-cli/pull/13195, and they only need to be exposed.
Most helpful comment
@jiasli yeah, it makes sense.
However, if you use
az cliin a script, it means each user has to implement their own forks for SP/user again and again in some cases. It would be great ifaz clican adapt based on the current authentication since it already has all required data and knows the auth mechanism.