Azure IAM RBAC changes can take anywhere from a few seconds to 30 minutes to propagate through their system! Yes, you read that right: 30 minutes. Azure IAM permissions can be very delayed.
This results in the UI and CLI or API always matching. Eventually, it resolves itself but it can be very confusing if you’re not aware of this. Particularly, the Assign a role to the application is inconsistent and will not have a fresh list of the available members.
CLI Session Tutorial
I’ve found that sometimes checking the permissions in both CLI and UI to verify helps. Below is an example session of checking the permissions with the CLI.
Start with Client ID
CLIENT_ID=186cc353-365a-41a6-9c3a-7e464ef13533
❯ az ad sp show --id $CLIENT_ID
{
...
"displayName": "test user",
"id": "EXAMPLE8-35c4-4a9b-a4a2-4besiEXAMPLE"
}
❯
You’re looking for the id - that’s the “assignee” ID. The from above is ID is the Service Principal ID. In this example: EXAMPLE8-35c4-4a9b-a4a2-4besiEXAMPLE
Assign some variables to your own values. Example:
SUBSCRIPTION_ID=EXAMPLE8-c44e-4677-bf0e-6c380EXAMPLE
RESOURCE_GROUP=my-resource-group
STORAGE_ACCOUNT=uniqstorageacct7057
Assign the role
az role assignment create --assignee EXAMPLE8-35c4-4a9b-a4a2-4besiEXAMPLE --role "Storage Blob Data Contributor" --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Storage/storageAccounts/$STORAGE_ACCOUNT"
Verify at Service Principal
az role assignment list --assignee EXAMPLE8-35c4-4a9b-a4a2-4besiEXAMPLE --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Storage/storageAccounts/$STORAGE_ACCOUNT"
echo "Checking role assignments for the storage account:"
az role assignment list --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Storage/storageAccounts/$STORAGE_ACCOUNT" --query "[].{principalName:principalName, roleDefinitionName:roleDefinitionName, principalType:principalType, scope:scope}" -o table