DEV Community

Wai Liu
Wai Liu

Posted on • Updated on

Accessing Power Platform in DevOp Pipelines using Service Principals

The Power Platform is really great for building things quickly
but at some point - especially in an enterprise environment, you're probably going to want to use DevOps to export your code into a source repo and do deployments to higher level environments.

This article outlines the first step which is to establish a way for a DevOps to authenticate and access a Power Platform environment

User account or Service Principal

DevOps uses Service Connections to authenticate against environments and you really have two types. You could create a Service Connection that just uses a standard user account or you could use a Service Principal.

With a user account, this will be treated like a normal user - so there may be license implications and is generally not the recommended method. With just a tiny bit of effort we can use Service Principals and therefore this is what I'll be demonstrating with.

Prereq.

  • You will need to access your Azure Active Directory tenant and be in one of the following roles:
    • Application administrator
    • Application developer
    • Cloud application administrator
  • You will need to access your Power Platform environment and need to be a System Admin
  • You will need to have DevOps permission to create service connections. You may also need further access to do things within DevOps depending on what you actually want to do with service connection (eg. create pipelines, save to repo)

Set up App Registration

Go to Azure Portal -> Azure AD -> App registration. Create a new registration.

App Registration

Enter details and press Register
Image description

Take note of the Application ID and Tenant ID (you'll need it later)

Register

Create a client secret

Go to the Certificates and secrets page and create a new client screet.

Image description

Just a few things here - the maximum length of time you can do is 2 years on the Azure Portal. You have two choices here - set a little reminder to regenerate this secret and change it for the places that use the secret, or there's also a way using PowerShell to create a secret that lasts up to 100 years (see this answer)

The other issue you might want to consider is where to store the secret. The secret is only shown once and then you cannot retrieve it after that. If you need to use it later on, you'll need to somewhere to store it - I would recommend using Azure Key Vault - and you can even then access it programmatically if you want to. In my case, I'm not going to store the secret anywhere. The only thing I'm going to use this secret for is my Service Connection, so I'm happy to re-generate a new secret if I ever need to edit this.

Inside your Power Platform environment

Next we want to create a user that the app registration will be connected to in Power Platform. The app registration will be able to act on behalf of this user.

In Power Platform environment, go to Advanced Settings -> Settings -> Security -> User and then Application User -> then click New

Image description

Paste the Application ID in and it'll re-populate the rest of the fields.

Image description

Grant this user system admin access.

Image description

Create new Service Connection in DevOps

Under Project Settings -> Service Connections, create a new service connection

Image description

Select Power Platform

Image description

Enter in all the details noting you'll need the tenant ID, application ID and client secret ID

Image description

Utilise the Service Connection

A screenshot below shows a step in a pipeline which is an example of where you may use this Service Connection

Image description

Summary

This article shows how to set up the Service Principals in order for your DevOps pipelines to access your Power Platform Environment. In later articles, I will explain things you can do with this access which may include exporting and unpacking to save to a new git branch or creating release pipelines that'll automatically import and publish your solution into higher level environments as required.

Discussion (0)