Choose secure Power Platform pipeline authentication
Diesen Beitrag auf Deutsch lesen
Compare client secrets, managed identities and workload identity federation for Azure DevOps Power Platform service connections.
TL;DR
Power Platform Build Tools service connections support client secrets, Azure Managed Identity and workload identity federation. Federation uses a short-lived Azure DevOps token and needs a federated credential plus a Dataverse application user. Managed identity requires a self-hosted Azure agent, while client secrets require expiry management.
Original by Zsolt Zombik, on Practical AI, Copilot & Modern Development Insights. Read the original
This is our own summary, not a republication or full translation.
Governance takeaway
- Admins/CoE: Create a Dataverse application user with an appropriate role for every target environment, regardless of the connection method.
- Security/Compliance: Prefer short-lived federation where policy allows, and review preview approval requirements before production use.
- Admins/CoE: Keep Grant access permission to all pipelines unchecked and authorize pipelines individually.
- Makers: Check PowerPlatformSetConnectionVariables and direct pac scripts before moving a pipeline to federation.
Frequently asked questions
How does workload identity federation authenticate a Power Platform service connection?
It exchanges a short-lived Azure DevOps OIDC token with Entra. The application needs a federated credential and must exist as a Dataverse application user.
Why cannot Microsoft-hosted agents use Azure Managed Identity for Power Platform Build Tools?
Microsoft-hosted agents do not support managed identities. This option requires a self-hosted Azure VM agent or an agent pool with the relevant identity.
What issuer and subject should I use for a federated Power Platform service connection?
Use the issuer and subject shown by Azure DevOps on the connection. Older published values may not match newly created connections.