Closed andreireznikau closed 3 years ago
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Wmengmsft, @MehaKaushik, @shurd, @anfeldma-ms
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @armleads-azure.
Author: | andreireznikau |
---|---|
Assignees: | - |
Labels: | `ARM - RBAC`, `Service Attention`, `customer-reported`, `question` |
Milestone: | - |
hello @dagoroz, I see it was done very recently. What should we do to make it work?
@eosfor if it's possible for you to use Az.Resources 3.0.1 please do that If there is a hard limitant that does not allow you to do that I'm going to have to request a little patience
I'm currently working on a fix to reestablish the 3.0.1 functionality in a way that doesn't break users.
@dagoroz Following up to see if there is any update on this issue? - Thank you
this was solved long time ago closing
Thanks for the update @dagoroz
Description
There is the Azure Policy is set against management group to allow roles granting privileges to SPNs from particular groups only.
We have the release definition task to assign an MSI "DocumentDB Account Contributor" role to CosmosDB account on behalf of SPN which meets the policy criteria on build agent and get the release failed with the below exception:
We have the same exception running the definition either on Microsoft Azure Pipelines agent pool (windows-2019) or running New-AzRoleAssignment directly from PS session on self-hosted build agent. However it works fine from my local machine. I compared debug output from both session and found the only difference in http request: on the local machine request body contains "principalType": "ServicePrincipal", pair while the request body from the build agent does not.
Local machine:
Build agent:
Steps to reproduce
Environment data
Module versions
Debug output
Error output