Power Platform | Pipelines – Design a security concept

You may have heard about my mini-series I did for reviewing Power Platform Pipelines. The easiest way to check this out is starting here, if you missed it. Ever since there´s been an episode on XrmToolCast with my MVP friends Scott and Daryl where we had a chat about the Application Lifecycle Management capabilities around this new Power Platform Power Apps in-app experience. Thanks for having me on your show. You prefer watching the video instead of just listening? Here you go. Today, I´d like to review the security roles that are brought with this solution and providing some food for thought on an architecture design which I recently reviewed from an enterprise customers planning to use Pipelines.

The Admin security role

Let´s start with a look at the role that you would assign to those typically in DevOps who would overlook the ALM process and should be able to setup, monitor and inspect the various deployment pipelines and -stages. You would assign them the Deployment Pipeline Administrator role.

Remember these roles are coming with the solution itself, which means you will find them in every Host you´ve installed the Pipeline solution for. This is pretty important in terms of the current limitation that you need to have a Pipeline Host in every region you are having Development, Test/QA and Production type environments. In other words a Developer creating the artifacts in a US region based developer environment will not be able to deploy the solution to EMEA or ASIA based Test/QA or Production type environments.

As you can see from the screenshot above your users in DevOps not only would be allowed to administrate Pipelines, they are also allowed to use Pipelines created. The permission granted is Org-wide (green circle). This is important to understand when you´re considering the role assignment been done not on a per User level, instead using Azure Active Directory Security Groups and assign the role via the membership of this group.

To learn more about this concept, I recommend yours watching the recent The Low Code Revolution episode where Daniel and Prabhat are talking about this in more detail.

Enterprise Architecture

As I outlined earlier, I was tasked to review an enterprise architecture design for using Pipelines in an organization. To provide more context, think of multiple developers would work in shared developer environments. It was essential to challenge, if all those developers should be assigned the Deployment Pipeline Administrator role, due to specific security requirements. Furthermore, developers where basically located across the globe which in terms of using a single Pipelines Host would fail due to the fact of having multiple Test/QA and Production type environments being in different regions. The customer furthermore considere more sophisticated developers to be able to create their own pipelines in each region them developing solutions for. Them being capable of managing, monitoring and inspecting of what´s ongoing + supporting other Makers using Pipelines to deploy their solution artifacts as well. Obviously this becoming a challenge everyone being granted the above security role.

So what´s an option here?

The user security role

You may ask now, if the user security role might be the solution to be used in an enterprise architecture. So let´s find out by taking a closer look at it.

Reviewing the privileges granted with this security role, you can see, why a deployment pipeline created by an Admin would need to be shared with the User for them to see the pipeline becoming available in the Pipelines solution. The security role grants them user-specific read permissions for both the Deployment Pipeline and -Stage table to allow for exactly this scenario.

In an enterprise scenario you again would make usage of Azure Active Directory Security Groups to assign this role via membership of the security group, instead of going user-by-user level, sharing and granting privileges.

Enterprise architecture continued

In our enterprise architecture where multiple Makers should be equipped to deploy their created artifacts via solutions from Development to Test/QA and finally to Production type environment(s), you again need to consider the privileges granted with this end-user Deployment Pipeline User security role. While for the majority of Makers (think Business Technologists) this role and the sharing of Pipelines by Admins might work in practice, more sophisticated Makers might ask for a kind of interim role, which „sits“ between both provided out of the box security roles. Personally, I would love to see another role being added where more sophisticated Makers would be allowed to at least create, monitor and manage their own Pipelines without being granted the high security privileges on the overall company-wide Pipeline Host(s).

With the upcoming Pre- and Post-stage extension which would allow to implement approval and review scenarios prior to deployment stages, this role could also help with the Fusion Teams development concept. I´ve been creating software artifacts within both Dynamics 365 and Power Platform from the early beginning the solution concept being introduced. A rule of thumb always was to have a review done by another person as you tend to test the code / solution in the way you designed / developed it and this may not be the only way your users consider to use your solution. Another aspect was to collaborate and develop in teams and merging artifacts to compact solutions prior to them being deployed.

In our current architecture design review, we ended up going with a Pipelines Host in each region for managing Pipelines. We created a custom role as a copy of the user-role to allow for more sophisticated Makers becoming „Managers“ of their own Pipelines while DevOps Admins remain responsible for an overall quality / review aspect in each region. A concept that was inherited from the CoE implementation of this customer.

As always, let me know via the comments what your experiences are with using Pipelines in your company. Until then, happy easter holidays for those celebrating or taking a time off to relax and reload energy…