0

There is this Azure function that needs to call Azure REST API.

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/config/web?api-version=2019-08-01

And the function should have the least possible permissions. I have a custom role (cloned from subscription level contributor), assigned to the function at the subscription level. The JSON is below:

{
    "properties": {
        "roleName": "Web config contributor",
        "description": "Custom role that can read resources under subscription and update their web config.",
        "assignableScopes": [
            "/subscriptions/def-abc-45346-9477-xyz"
        ],
        "permissions": [
            {
                "actions": [
                    "*/read",
                    "Microsoft.Web/*"
                ],
                "notActions": [
                    "Microsoft.Authorization/*/Delete",
                    "Microsoft.Authorization/*/Write",
                    "Microsoft.Authorization/elevateAccess/Action",
                    "Microsoft.Blueprint/blueprintAssignments/write",
                    "Microsoft.Blueprint/blueprintAssignments/delete"
                ],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}

The only point it seems to work is if the actions is set to *. Else it throws 403 (Forbidden). I have tried:

"Actions": [
    "*/read",
    "Microsoft.Web/sites/config/Write",
    "Microsoft.web/sites/config/delete"
  ]
"Actions": [
    "*/read",
    "Microsoft.Web/sites/*"
  ]
"Actions": [
    "*/read",
    "Microsoft.Web/*"
  ]

What is the way to figure out what actions are to be allowed on the custom role for the REST operation to work?

dushyantp
  • 4,398
  • 7
  • 37
  • 59

1 Answers1

1

Based on my test, Microsoft.Web/sites/config/Write is enough.

My custom role for your reference.

{
    "properties": {
        "roleName": "testrole005",
        "description": "",
        "assignableScopes": [
            "/subscriptions/e5b0fcfa-e859-43f3-8d84-5xxxx29fxxxx"
        ],
        "permissions": [
            {
                "actions": [    
                    "*/read",
                    "Microsoft.Web/sites/config/Write"
                    ],
                "notActions": [],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}
Allen Wu
  • 15,529
  • 1
  • 9
  • 20
  • Could it be the `notActions` in my custom roles! Will try and get back. – dushyantp Jul 28 '20 at 10:04
  • Sorry for the delay. Still getting `403 (Forbidden)` with those actions and removing `notActions`. – dushyantp Jul 29 '20 at 09:57
  • Now it is intermittently working, every few runs it succeeds, and in other runs throws `403`. I am trying to figure out if something sinister is going on. Your answer should be correct and after a bit more investigation I can accept it. Only difference is, I am using `"Microsoft.Web/sites/config/*"` instead of `"Microsoft.Web/sites/config/Write"`. – dushyantp Jul 29 '20 at 15:31
  • @dushyantp I have repeatedly deleted and added my custom role, and can clearly see that it works. Would you like to share your function code so that I can investigate further? – Allen Wu Jul 30 '20 at 02:27
  • @dushyantpd Besides, if you have to use `"Microsoft.Web/sites/config/*"`, you can exclude the `Microsoft.web/sites/config/delete` or `Microsoft.web/sites/config/read` and so on in `notActions` to have a test. – Allen Wu Jul 30 '20 at 02:29
  • Unfortunately cannot share the exact code (internal company work). I am just following this blog http://blog.davidebbo.com/2015/12/calling-arm-using-plain-rest.html and calling HttpClient.PutAsync to update web config on a list of function-apps. – dushyantp Jul 30 '20 at 07:30
  • 1
    @dushyantp No problem. If so you could follow my suggestion about excluding the unnecessary permission in `notActions`. Hope it helps. – Allen Wu Jul 30 '20 at 08:03
  • Ah! @Allen Wu your answer is correct. This function is updating the `network restrictions` in the config as well and in the process is locking itself out (refer https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions). So it works the very first time it runs and fails in subsequent ones. Sorry for taking so long to figure this out! This is development phase and I will continue using `Microsoft.Web/sites/config/*` and will look to cut down further later. Thanks for your help. – dushyantp Jul 30 '20 at 08:26
  • @dushyantp I'm glad to know that this issue is resolved. – Allen Wu Jul 30 '20 at 08:30