When deploying from one stage to another in Deployment Pipeline, it would be great if we could use a Service Principal connection (or Workspace Identity, Managed Identity) to do that.
Meaning, I could interactively - in the user interface - pick a Service Principal deployment pipeline connection* that I have User right on, and use this Service Principal connection to make deployments.
The Service Principal would need to be at least Contributor in the target (destination) workspace.
I would like to be able to choose another identity (connection) for the source workspace. So, I could use separate identities for the source workspace and prod workspace.
This way, we could have isolated identities in dev/test/prod, so we have water tight compartments between environments.
My own user doesn't need to have write access in test and prod - I just need to be a User of the service principal connections which are allowed to deploy to test and prod, respectively.
The benefit of having isolates identities in dev/test/prod is that we avoid the risk of accidentally writing dev data to prod and vice versa.
Today, a user needs to be Contributor in all workspaces (Dev, Test and Prod) in order to make deployments. Because the same identity (the same user) has Contributor permission in all workspaces today, it means there is a risk that this identity reads data from Dev and writes it to Prod, or vice versa. To avoid this risk, it would be great if we could use separate identities (service principals, managed identities) in dev/test/prod and just use our user account to trigger the deployments.
In practice, it is likely that my user would still have Contributor permission in Dev, in order to do development, but my user should not have Contributor permission in Test and Prod - it should only have User permission on the Service Principal connections so that I am able to to deployments to Test and Prod, without having write permission (contributor) in Test and Prod workspaces myself.
* Deployment pipeline connections would be a new feature.
... View more