You may have already recognized me stepping into the Power Platform Pipelines topic from two different scopes. So I started with sharing some thoughts via an article that concentrates on the role of a Maker using Pipelines in their creation process of solutions. I then followed by taking a look at the Admin experience, before rejoining the Maker path again – talking about them using Environment Variables when deploying their solutions to various environments, switching connection reference endpoints – e.g. like an SAP System in Dev-, Test-, and Prod-Environment where each of them obviously is having a different IP address.
Today, I´d like to switch back on the Admin side again, talking about the security model behind Power Platform Pipelines. Sharing some thoughts around this and providing some tips of avoid running into a long-term maintenance issue.
When you install the Pipelines solutions and configure it to run inside the Pipelines Host environment, you do have two security roles that are deployed and offered out of the box. Those security roles should be considered to control the access level of the Pipelines Deployment Configuration App – or who is having access in which role.
Let´s say in daily practice and operating in a DevOps model, a team of Admins would need to be assigned the Deployment Pipeline Administrator role, if you want them to have full control over all pipeline configuration, without assigning them the system administrator security role of that Host environment. Those Admins would then be capable of designing and configuring pipelines as well as sharing those records with other Makers – them to become enabled of using Pipelines from within one of their Environments (Dev, Test, Prod – to name examples).
Admins therefore would typically use above UI to share the created pipelines with Makers inside their organization, which could be done individually (User by User), a team (offering Team name) or centrally managed via a security group. In any case you only need to assign those Makers the Read permission.
In day to day manner, you may now carefully consider the amount of work in the configuration setup of this via UI vs. automating these steps and include it as being part of your DevOps process in general – how? With the help of Power Automate as an example.
I should also mention, that the user using Pipelines in their Development, Test or Production environments also should be assigned the Deployment Pipeline User security role as seen in first visual. Only this combo would allow them to use Pipelines. But wait, there´s another note which should not be missed – you need Export- and Import-solutions permission in both your Development Environment(s) as well as in any target Environment(s) you would deploy to. So you would need to consider a security role for this being assigned in each of those environments to them. Only this combination would allow you to have Pipelines running appropriate.
Considering now, you are one of those DevOps / Pipeline Admins and you have a lot of Developers and Environments to maintain, where could be a „shortfall“ of the current user experience? As you can see from the visual above, handling just a couple of active deployment pipelines might not be a big issue. Though, what if this list grows and there´re growing numbers of active pipelines to be maintained?
An issue this user experience – nor the current offered Power BI dashboard solves is: Which are the users you have been shared with those pipelines? A click row by row and opening the share dialog window, which will show you this information from UI perspective might become inconvenient over time, especially this list of active deployement pipelines growing or being a certain amount of rows for your organization.
Lucky those, who know there´s a third party tool called XrmToolBox which offers a tool created by Jonas Rapp called the FetchXML Builder. This tool allows us for using the FetchXML query language to receive information via the linked entity who we shared a row with.
In above visual I´ve created and executed this FetchXML query and as you can see it shows my two active deployment pipelines that I´ve been sharing directly with Carl Citzen (as you can see from the 2nd visual). You can´t see Carl Citzen as Display name, instead, you do find an attribute SharedWith_UserId in above screenshot, which contains the User GUID for Carl.
This tool also allows us to take a look at the FetchXML itself.
So for those not yet being familiar with Power Platform customizations and the structure of the view query language, you can now see how this looks like. Why am I sharing this?
This might be the starting point of considering to build another dashboard view for Power Platform Pipelines, that in daily practice would allow yours to monitor who you or your colleagues shared with the configured pipelines! Over the course of time using it, you certainly will no longer remember if you shared a pipeline with a single user, a team or a security role.
Conclusion
In a DevOps team, where certain tasks for monitoring and administration of ALM are to be executed – automatically, I would really love to see a dashboard or view like this offered out-of-the box in a future release of Power Platform Pipelines. In an enterprise world of having hundreds of environments and dealing with a couple of them being activated for usage within Pipelines + dealing with a larger amount of Makers that for maybe are aggregated or „hidden behind“ security groups, you certainly want to maintain your ALM solution in terms of a qualified auditing process.
Those system customizers, Makers or Developers being familiar with Power Platform in general might easily understand how to customize a solution that fulfills on those goals, though it´s not yet a configurative experience.
Please continue sending me your thoughts on using Power Platform Pipelines in practice and don´t forget: Please do keep it coming! You can comment this announcement and in the Power Apps community. Until then, …
The Power Platform Talks 
Ein Gedanke zu “Power Platform | Pipelines – the security model”