Automated method to determine required permissions for SDK calls for least privilege purposes

[domjancik]

When using SDK calls, it is unclear which permissions I need before calling and possibly getting an unauthorized error, which contains the required permission.

This is something that can be very useful when trying to set up a secure system and adhere to the least privilege principle.

I found the documentation page about this topic, but it contains just a mapping between services and resource providers (eg. Azure Container Apps to Microsoft.APP). The actual permissions actions required by SDK/API calls seem to be left to guesswork and relying on undocumented conventions. This is hard to automate and use at scale.

https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles#how-to-determine-the-permissions-you-need

Suggested feature

Is there, or could there be a mechanism that would return a list of action permissions in response to a service/method pair?

Example:

Request:

{
	"class": "ResourceManagementClient",
	"method": "list"
}

Response:

["Microsoft.Resources/subscriptions/resources/read"]

Alternative solutions

I tried researching the SDK and REST API documentation, in hopes that the required permissions would be documented there and could be scraped.

I also considered using REST API URLs as hints to the permission names as they seem fairly close. I do feel that there will be gaps with this approach and also not sure how to map between REST API calls and SDK functions.

[azure-sdk]

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'Search:0.049442086,App Services:0.04004268,Docs:0.03406554'

[annatisch]

Thanks for your question @domjancik - certainly an interesting feature.

I would say this is possibly something that would be difficult to support in the SDKs unless there was underlying service support for it - as the only option would be to maintain a local mapping of requests to permissions which - given the breadth of Azure services - would likely become out-of-date the day it was published and would very quickly become unreliable and difficult to maintain.

I have tagged the mgmt team to see if they can provide any further details on whether there exists a best practice for retrieving this information.

I suspect from an SDK perspective, one approach that we could take would be to better handle AuthenticationErrors errors that contain the necessary permissions, so that these could be easily parsed to surface the necessary information so those permissions can then be requested.

[domjancik]

Thanks @annatisch, I understand that it would be difficult to keep up to date manually.

I was hoping that you have the mapping somewhere internally - used to actually make the access control work.

It would be great if AuthenticationErrors were displayed with all included information from the HTTP response. However, I've noticed that storage APIs do not respond with a list of missing permissions, just:

<?xml version="1.0" encoding="utf-8"?>
<Error>
    <Code>AuthorizationPermissionMismatch</Code>
    <Message>This request is not authorized to perform this operation using this permission.
RequestId:61c8d2ee-701e-0064-78ab-79dd58000000
Time:2022-06-06T13:46:27.6525102Z</Message>
</Error>

I'd definitely like to hear what is the best way to approach this problem with what is available.

[domjancik]

Out of curiosity, can required permissions for an SDK call change depending on the supplied API version?

[domjancik]

@BigCat20196 Hi, have you looked at this issue?

Is being able to get the required permissions something you could be looking into in the future?

[msyyc]

Hi, as annatisch said, SDK is just tool to send/receive http request/response. So your feature is more about feature-request for ARM. I advise you open an issue in https://github.com/Azure/azure-rest-api-specs/issues

[ghost]

Hi @domjancik. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[ghost]

Hi @domjancik, since you haven’t asked that we “/unresolve” the issue, we’ll close this out. If you believe further discussion is needed, please add a comment “/unresolve” to reopen the issue.