Microsoft states that Microsoft.Authorization/roleDefinitions/read
permission is needed to read RBAC role definition.
It is mentioned here https://learn.microsoft.com/en-us/rest/api/authorization/role-definitions/list?tabs=HTTP
However I have Azure application which has assigned empty role (having 0 permissions) and still can read role definitions.
How is that possible?
This is the empty role which the Azure app is assigned in subscription S1:
{
"assignableScopes": [
"/subscriptions/<S1 ID>"
],
"description": "No Permissions role",
"id": "/subscriptions/<S1 ID>/providers/Microsoft.Authorization/roleDefinitions/<role ID>",
"name": "<role ID>",
"permissions": [
{
"actions": [],
"dataActions": [],
"notActions": [],
"notDataActions": []
}
],
"roleName": "No Permissions Role",
"roleType": "CustomRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
The app is not assigned any other roles in the subscription S1 (nor in any other subscription).
"Check Access" for the app in S1 confirms that:
When logged in with this app into Azure CLI it lists role definitions just fine, e.g. Contributor:
C:>az login --service-principal -u <app ID> -p <client secret> --tenant <tenant ID>
C:>az role definition list --name "Contributor"
This command or command group has been migrated to Microsoft Graph API. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
[
{
"assignableScopes": [
"/"
],
"description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
...
"permissions": [
{
"actions": [
"*"
],
...
}
],
"roleName": "Contributor",
...
}
]
Azure CLI is authenticated using az login --service-principal -u <app ID> -p <client secret> --tenant <tenant ID>
2
Answers
This could be done if the application was given permission to read role definitions at a higher level of the hierarchy, such as the management group or tenant level.
In few scenarios, Azure subscriptions provide a default role "Reader", which grants read access to most of the Azure resources. And this role includes the
Microsoft.Authorization/roleDefinitions/read
permission.Run the below command in Azure CLI to check the application’s subscription-level access.
Note: Instead of the subscription scope, give the management scope to retrieve the role assignments at the management level.
Alternatively,
If still the issue persists, try reaching out to your admin and restrict the access.
While it may seem contradictory, this is actually expected behavior. The document you referenced does state that Microsoft.Authorization/roleDefinitions/read permission is needed to read RBAC role definitions. However, this doesn’t mean it’s the only way to obtain read permissions.
Azure has a concept of "built-in roles" that are applied at a root level ("/") and cannot be removed or modified. The built-in "Reader" role provides access to view all resources, including role definitions, even if the custom role assigned doesn’t explicitly list the "Microsoft.Authorization/roleDefinitions/read" permission.
Even when a custom role is created with no permissions, Azure still maintains a minimal level of access for service principals. This includes read access to some basic information about the Azure environment and resources, which is necessary for various Azure operations.
While you’ve mentioned that your app only has this custom role assigned, it’s possible that it still has inherited permissions from elsewhere, such as from a built-in role.
If you want to make sure that the app does not have any other permissions, you can verify this by checking the "Access control (IAM)" section in Azure portal for each resource that the app can access, or by using the command "az role assignment list –assignee " in Azure CLI.