Azure Resource Management API without user_impersonation, is it possible?

Question

I am trying to find security best practice on App permissions in the context of azure resource management.

Currently, there is only one permission listed for management.azure.com and it is management.azure.com/user_impersonation (preview). This delegated user impersonation can be a serious problem and it can led to account takeover by malicious app.

Think about a scenario where a user with global administrator role consent and authorize an access token to the app. App can use the token and do whatever it wants with the azure tenant.

Another scenario where a privileged user assigned contributor role to multiple subscriptions. Token authorized by this user can be misused by app to modify resources in any of the subscriptions.

Unlike graph (graph.microsoft.com) api where you can handpick the permission (user.read), resource management api has only one option - user_impersonation!

You may argue why would a privileged user authorize the action but people make mistakes. Our job is to stop or minimize such risk by design. So, what's the best way to allow app to manage resources in azure and minimize the security risk?

Answer 1

Thanks to @juunas for outline and tips. Thanks to @Gaurav for attempting to address my question. I was able to modify azure resources on a subscription without having to grant user_impersonation on management.azure.com api. Here are the steps-

1) Register an app (TestPermissions in my case)

2) Add API Permissions (optional). You don't need to add management.azure.com.

3) Go the Azure resource (subscription, resource group or management group level based on your requirement) and add IAM/RBAC role to the registered app. I assigned Contributor role to TestPermissions app at the subscription level.

4) Request a oauth2 access token following client credential grant flow. You can provide client_id and client_secret in the body of the POST request or you can provide it as Authorization Basic base64 encoded header (that's what I did). Save the access token for future use (until it expires).

Note: I could not add multiple audience (scope) at the same time. If you would like to get a token for graph api, you can request a separate token by changing the scope to http://graph.microsoft.com/.default

5) Use the access token captured in the previous step to interact with azure resource manager. You will need to add the jwt bearer token in the Authorization header (not shown here) on every request to https://management.azure.com. In this example, I am creating a new resource group named TestCreateRG003 to one of my Pay-as-you-go subscription.

6) Let's validate/verify that the resource is created or updated in Azure. Bingo, there they are! App can read/modify (based on RBAC) azure resources w/o having to grant impersonation permission.

Answer 2

It is true that by granting that permission you are allowing the app to act as you, with all the permissions that brings.

The main way I've seen used when limitations are desired is that you:

• Register an app in your Azure AD
• Grant the service principal the necessary roles (e.g. Reader on specific resources)
• Set the tenant id, client id, client secret etc. in the app

This of course requires that the app itself supports this approach. If it only allows usage through impersonation, then you'll need to either trust or not use it.

Answer 3

Let me see if I can answer this question.

When a user requests a token for management.azure.com, all is done at that time is that the user has permission to execute Azure ARM API. That doesn't mean that they can do everything that's possible with Azure ARM API.

The things that they can do is controlled by Azure Role Based Access Control (RBAC). So if a user is in the Reader role, the token got on behalf of the user can only read information about resources in their Azure Subscription. They will not be allowed to create, update or delete resources in their Azure Subscription.

What you will need to do is grant users appropriate RBAC role to minimize the risks of misuse.