Deployment Pipeline - Deploy as Service Principal

Problem

Today, in Fabric Deployment Pipelines, a user must have Contributor access in all stage workspaces (Dev, Test, and Prod) to perform deployments.

 

This design means the same user identity has read and write permissions across every environment, which creates unnecessary risk. A user could accidentally read data from Dev and write it to Prod, or the other way around.

 

 

Proposed Solution

Allow deployments between stages to use isolated identity connections, such as:

 

• Service Principal
• Workspace Identity
• Managed Identity

 

This would let a user act as an orchestrator of deployments, rather than the identity that actually performs the writes.

The user would no longer need Contributor access in all workspaces - only User access to the defined identity connections that handle deployments on their behalf.

 

Suggested Implementation

When configuring a deployment pipeline, users could select an identity connection (Service Principal, Managed Identity, or Workspace Identity) in the user interface.

 

The selected identity must have at least Contributor access in the target (destination) workspace.

 

Users could select a different identity connection for the source workspace, allowing for complete isolation between Dev, Test, and Prod.

 

Each environment could therefore have its own dedicated identity, ensuring watertight separation between stages.

 

The user account itself would typically still be Contributor in Dev (for development work) but only User on the Test and Prod deployment connections. This maintains convenience for deployments while preventing direct modification of production resources.

 

Example:

• SPN_dev (Contributor in Dev)
• SPN_test (Contributor in Test)
• SPN_prod (Contributor in Prod)

The user (me) doesn't have Contributor access in the workspaces. I only have User access on each SPN's Deployment Pipeline connection. This means, I can trigger deployments without having Contributor permission in the workspaces myself.

 

Of course, if I don't have User access on each SPN's Deployment Pipeline connection, I will not be able to deploy content to the workspaces. This is how we will ensure that no unauthorized users can use the deployment pipeline.

 

What are the actual changes?

At it's core, this proposal introduces two changes (new features):

• The concept of shareable Deployment Pipeline connections. (Inspired by data source connections).
• The ability to use separate identities (separate deployment pipeline connections) for the source and target stage, in order to orchestrate the deployment across stages - without a single identity having Contributor permission in both workspaces.