Proper RBAC needs for Azure Policy Export and GitHub
Are you authorized properly for this feature
After talking with a customer on Azure Policy Export to GitHub we encountered an error a user account was running into. On the final page of the Review and Create button validation would fail “You do not have rights create/modify resource policy“.
I wanted to walkthrough some quick thoughts and findings.
To begin with the error does indicate it is more than likely a RBAC \ Role \ Authorization error that is occurring. What is odd though is the user using the feature is assigned a Standard built in role at the Azure Subscription level of Resource Policy Contributor. In fact this role allows you to create, modify, and remove Azure Policy definitions and assignments.
In testing we know that a user with Contributor or Owner role will work. Microsoft recommends eliminating and reducing the amount of resting permissive authorization and permissions a user has. In order to uncover what additional permission may be needed to use this feature we can open our Developer Tools in our browser to see what APIs might be called that are preventing this.
To do so we will open a browser and go to portal.azure.com and log in with a user who is not running into the error and we will go to a Policy Definition using the Export to GitHub button, walking through the steps we will pause and open the Developer Tools before the Review+Create to see what is happening behind the scenes in the portal.
With developer tools open we will go to the Review+Create screen and execute the Export monitoring the API calls being made.
In the first call we can see a POST being made to the old AAD Graph.windows.net API to create a AAD Policy with App Registration
In another call we can a POST to the old AAD Graph.windows.net API to create a Service Principal
In fact after the Export Policy is executed you can see that your AAD now has a Service Principal created with RBAC Rights to the Subscription with the very same Resource Policy Contributor. - This makes sense because the GitHub Actions will rely on this Service Principal to authenticate and be authorized to update Azure Policies when you check in a new policy into GitHub and execute new versions of the policy or assignment. This process appears to a glue \ linking.
One final interesting API a POST to ExportConfiguration call. *Note this is an upstream API, Azure portal will use upstream APIs from time to time to do some other things especially in Azure Features like this. While we can’t interact with these directly like Azure Resource Manager or Graph APIs, we can see it is designed to Interact with GitHub APIs and create the Glue \ binding on that side by exporting the policy configuration into GitHub repo we selected earlier.
Having an understanding of the APIs being called and using Developer Tools can be a useful way to understand what the Azure Portal is doing. With this knowledge you can use to generate automation using Logic Apps or Functions you’ll want to know programmatically how a feature or what the portal is interacting with Azure Resource and graph APIs.
In our customer case I presented the findings with our engineering team and they indicated that an additional permission was needed, since we are generating SPNs and Assigning those SPNs the Resource Policy Contributor role an additional permission the user needs when exporting is Microsoft.Authorization/roleAssignments/write
Due to this the user having Resource Policy Contributor is lacking the ability to write role assignments for that SPN being generated acting as a glue for GitHub Actions.
To help with this and not assign Owner or Contributor role to a operations team or a security admin who wants to use Export Policy to GitHub features. You can create a Azure Custom Role and assign to the user.
To do this you can simply export an existing Role: Resource Policy Contributor and add the permission needed Microsoft.Authorization/roleAssignments/write to the custom role being created and you can do this with the Azure Portal.
Once Create you can assign the new Azure Custom Role to a Security Group or a User to grant them the access needed o work with this feature.
One last note you need to be careful of Creating Azure Custom Roles and in this case the standing access you have granted could let the user or a compromised user manipulate role assignments.
If you have Azure Privileged Identity Manger (AAD PIM) please use this for the role assignment so that it is not standing access.
In addition be sure to monitor the AAD Sign Ins and Azure Activity Logs for any suspicious activity around this.
Finally please take note of the Azure Security Compass deck on Azure Custom Roles for guidance.
I have a small project I need to revisit from last year but the idea was upon creation of a Azure Custom Role in your Enviroment, the role is scanned for Risky APIs and reported. This one would have been flagged.
In addition I have also uploaded the Custom Role created here: