Power Platform ALM: Azure DevOps service connection permissions on Test/Prd environments?

[Union3008]

As suggested by Microsoft, we have dedicated DEV environments for each business unit, and shared Test/Prd environments for deploying solutions to production.

For deploying solutions, we use Azure DevOps and Power Platform Build Tools in order to import solutions in Test/Prd using automated pipelines. As recommended, our AzDo pipelines authenticate to Power Platform using service connections with service principals and secrets.

The problem starts when Microsoft recommends giving the service connections System Administrator roles on the target environments. I am not sure how this is even a recommendation, as it allows a service connection to delete any solution deployed by other service connections, or even delete the whole production environment while at it.

To overcome this problem, we gave AzDo service connections the Environment Maker role instead, which gives them just enough permissions to create/update/delete solutions that they own/deployed. This is critical for our organisation as Business Units all have their own AzDo project, and one Business Unit should not be able to update/delete another Business Unit's solution.

However, when giving service connections the Environment Maker role, another problem appears when trying to import a solution that contains a Dataverse security role: A user (service connection) cannot create/import a security role that has more priviledges then itself. This means a simple security role that gives access to a dataverse table that is part of the imported solution is enough to throw an error since the Environment Maker role doesn't have access to custom entities. We considered giving service connections the System Customizer role but then it would give them access to all custom entities, and to be honest I am not sure of all other powers it could give against solutions deployed by other service connections...

I assume I am not the only one trying to automate deployments into shared Test/Prd environments, but I am still struggeling to find any relevant information on this specific subject. To me it seems like a major missing block that Microsoft brushes off their shoulders by recommending the use of System Administrator, but I don't see how this can be an option for any serious organisation? Anyone here tackled the problem?

Thanks!

[Union3008]

For those interested, I opened a case with Microsoft and they pretty much said that in order to be able to import a solution that contains a Dataverse Role using the build tools, my only choices are :

- Give service connections System Administrator (Or System Customizer with the CreateRole/WriteRole added)

- Limite the use of service connections to a specific group of admins

The first option is obviously a security issue, the second option kind of goes against the purpose of Power Platform to empower users to build and deploy their own solution: it would decentralize the development to everyone but centralize all deployments towards a specific group of admin that will do this 24/7...

[eleung83]

You could expand the 2nd option by also making use of approval gates in your release pipelines in Azure devops and as well as applying security at an environment level so the users can do limited actions.

There are various ways you could control the security here:

1. Blocking users from being able to deploy manually to your Tst/Prod environments. They can do whatever they wish in Dev but perhaps only have read access to any other environment. This also ensures your environments always stay in sync with no random changes being applied to one environment inadvertently

2. Users could setup build and release pipelines that publish to DEV, but they wouldn't have any credentials nor access to service prinicpals to use/configure in Azure Devops, which means they wouldn't be able to setup deployments to any other environment. 

3. You could restrict users from being able to setup release pipelines and instead delegate that to a separate team, so that the users could only approve releases.

I have seen this kind of security applied previously where I have been able to setup releases to environments where we have sys admin access (which are only relevant for developers) but there is another person responsible for configuring the rest of the release pipeline to other environments where we have limited access, and approval gates have been setup so only certain groups of users can then approve releases before they go to a specific environment. This then puts the control over releases down to the users/approvers.

[Union3008]

Yeah #1 is already done, users have read only access on Test/PRD which forces them to use a release pipeline in order to deploy.

We also have policies at the service connection level to make sure that releases using the PRD service connection have to come from the main branch, forcing developpers to do a pull request (which can enforce specific approvers) before releasing.

We will probably end up doing a mix of #2 specifically for releasing dataverse solutions: we want to let developers deploy by themselves as much as possible, but for deployments requiring the service connection to be Sys Admin (solutions with dataverse roles for example) these could be done by specific admins...

I just wish there was a way to let users deploy 100% by themselves without having a specific group of people to be a bottleneck in the deployment process, just like it's the case for our Azure service connections, which have access to create/update/modify/delete their own resources in azure but can't touch resources deployed by other Azure service connections. If Azure service connections had to be given Global Admin in azure in order to deploy resource groups it would be the same problem but it's not the case, to me it seems like a basic requirement in terms of ALM 😞