Power Platform: Installation & Configuration

To provision resources with the Pulumi Power Platform provider, you need Azure Active Directory credentials. Your credentials are never sent to Pulumi — they are used locally by the provider to authenticate against the Power Platform admin APIs.

Installation

The Power Platform provider is available as a package in the following Pulumi-supported languages:

Python

rpothin-powerplatform on PyPI

pip install rpothin-powerplatform

Node.js

@rpothin/powerplatform on npm

npm install @rpothin/powerplatform

.NET

Rpothin.Powerplatform on NuGet

dotnet add package Rpothin.Powerplatform

Go

powerplatform on pkg.go.dev

go get github.com/rpothin/pulumi-powerplatform/sdk/go/powerplatform

Java

io.github.rpothin:powerplatform on Maven Central

Gradle

implementation "io.github.rpothin:powerplatform:<version>"

Maven

<dependency>
  <groupId>io.github.rpothin</groupId>
  <artifactId>powerplatform</artifactId>
  <version>&lt;version&gt;</version>
</dependency>

Plugin installation

VERSION=$(curl -sL https://api.github.com/repos/rpothin/pulumi-powerplatform/releases/latest | grep '"tag_name"' | cut -d'"' -f4)
pulumi plugin install resource powerplatform $VERSION --server github://api.github.com/rpothin

Authentication

The provider supports several authentication methods. For local development, the Azure CLI is the simplest option. For CI/CD pipelines, OIDC / Workload Identity is recommended.

Azure CLI (recommended for local development)

Install the Azure CLI, then log in:

az login

The provider automatically discovers CLI credentials via DefaultAzureCredential. No additional Pulumi configuration is required when using the CLI.

DefaultAzureCredential (hosted environments)

When no explicit credentials are configured, the provider uses DefaultAzureCredential, which automatically tries multiple credential sources (environment variables, workload identity, managed identity, Azure CLI, and others) in a well-defined order. See the official documentation for the full chain.

This makes the provider work automatically in most Azure-hosted environments without any explicit configuration.

OIDC / Workload Identity (recommended for CI/CD)

Use federated credentials to authenticate from GitHub Actions (or other OIDC providers) without storing a client secret.

1. Configure federated credentials in Azure:

In your Azure AD app registration, add a federated identity credential for your GitHub repository:

• Issuer: https://token.actions.githubusercontent.com
• Subject: repo:<owner>/<repo>:ref:refs/heads/main (adjust for your branch or environment)
• Audience: api://AzureADTokenExchange

2. Add permissions in your GitHub Actions workflow:

permissions:
  id-token: write
  contents: read

3. Login using the azure/login action:

- uses: azure/login@v2
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    allow-no-subscriptions: true

After this step, the provider authenticates via DefaultAzureCredential, which picks up the Azure CLI session established by azure/login — no clientSecret is needed.

Service Principal (explicit configuration)

For environments where you cannot use CLI or OIDC, configure a service principal explicitly.

Via pulumi config:

pulumi config set powerplatform:tenantId <AZURE_TENANT_ID>
pulumi config set powerplatform:clientId <AZURE_CLIENT_ID>
pulumi config set --secret powerplatform:clientSecret <AZURE_CLIENT_SECRET>

Via environment variables:

Configuration Reference

Prerequisites

• A Microsoft Power Platform tenant with admin access
• An Azure AD app registration with the Power Platform API permission: https://api.powerplatform.com/.default
• Pulumi CLI v3 or later
• Python 3.10 or later available on PATH

Registering the service principal as a Power Platform application user

Most resources and invoke functions in this provider only need the app registration to be registered as a Power Platform “application user” — typically done with:

pac admin application register --application-id <AZURE_CLIENT_ID>

Elevated permission required for getDlpPolicies

powerplatform:index:getDlpPolicies (list all DLP policies in the tenant) calls the governance API’s tenant-wide “list rule-based policies” endpoint with no policy ID. Unlike every other DLP-related operation in this provider — DlpPolicy create/read/update/delete and getDlpPolicyMigrationConfig, which all operate on a single policy via its ID — this tenant-wide list requires the app registration’s service principal to hold the Power Platform Administrator Microsoft Entra ID directory role as an active assignment (not merely PIM-eligible, and not a Dataverse security role).

Without this role, the call fails with a bare 403 Forbidden and no response body, which gives no indication of what’s missing.

To grant it:

1. In the Microsoft Entra admin center, go to Roles and administrators.
2. Select Power Platform Administrator.
3. Add an assignment for the app registration’s service principal, as an active assignment (not eligible/PIM).

See Microsoft’s guidance on assigning Microsoft Entra roles to an app registration and on Power Platform admin roles for background on this specific role.

As of this writing, getDlpPolicies is the only function or resource in this provider confirmed to require this elevated role — everything else, including the AVM components, works with a standard application-user registration.