Permission Level and Scope in Managed Applications

We often meet some questions about permissions issues related to the managed applications. This blog will introduce the managed application by comparing the three aspects respectively.

• Service Catalog and Marketplace Application
• Application Resource Group and Managed Resource Group
• Deny Assignment and RBAC in Managed Application

Service Catalog & Marketplace Application

There are two kinds of managed applications.

The Service Catalog is an internal managed application. Users can see and download the Service Catalog that other people in their organization share with them.

The Marketplace Application is available to users outside of the publisher’s organization. Users can download this kind of managed application in the Azure Marketplace.

Reference: Overview of managed applications - Azure Managed Applications | Microsoft Docs

Application Resource Group & Managed Resource Group

There are two resource groups that are related to the managed application.

• Application resource group

The managed application instance will be saved in this resource group and the consumers who create the managed application will have full access to this resource group.

• Managed resource group

This resource group is created automatically in consumers’ subscriptions when consumers create the managed application. It contains all resources required by the managed application. The biggest difference between it and the application resource group is that it is automatically assigned a deny assignment when it is created. The different levels of operation permissions for this resource group will be granted by the publisher when the managed application definition is created.

When the consumer deletes the managed application, the managed resource group will also be deleted. The managed resource group cannot be deleted directly by the consumers because of the deny assignment.

Deny Assignment & RBAC in Managed Application

• Deny Assignment

Deny assignments block users from performing specific Azure resource actions even if a role assignment grants them access. For example, if there is a deny assignment on the specific resource group, even the user who has a contributor role on the subscription, this user still will be blocked by the deny assignment.

For the managed application, the deny assignment will deny all principles to do any updates for resources in the managed resource group by default. If the publisher does not assign herself/himself any role when she/he creates the managed application definition, she/he has no permission with the resources under the managed resource group as well.

• RBAC in Managed Application

The publisher can grant different roles to different users when creating the managed application. The RBAC assignment here will exclude specific principles with limited actions to operate the resources under the managed resource group.

Differences between Deny Assignment and RBAC in Managed Application

The deny assignment is used for denying the permission but is not used for authorizing permission. And the role assignment is used for authorizing permission for different users. If users are assigned roles, they will be excluded from the deny assignment for the specific permissions.

Taking the following deny assignment as an example, the “*/read” in the deny assignment means it only allowed the read operation. But if the user even does not have a role, it means the user has no permissions to do any operations to the resources under the managed resource group.

Reference: Understand Azure deny assignments - Azure RBAC | Microsoft Docs

Conclusion  

The following part will explain the above concepts again through a specific example.

In the managed application, the publisher assigns role1 to himself and assigns role2 to the consumer. The consumer creates a managed application instance in the application resource group under his subscription. The managed resource group is automatically created in the same consumer’s subscription. The publisher can do operations to the managed resource group that is officially defined for role1. (For the built-in roles, the allowed operations for a specific role can be found from Azure built-in roles - Azure RBAC | Microsoft Docs) Similarly, the consumer can role2 defined operations.