HEADS UP: Deny Assignment Permissions change

[snarkywolverine]

In the coming weeks, we will be relying on a new action for the management of Deny Assignments.

The action is: Microsoft.Resources/deploymentStacks/manageDenySetting/action

This permission will be required at the stack scope in order to do any of the following:

1. Create or update a deployment stack and set the DenySetting to a value other than "None"
2. Update or delete a deployment stack with an existing DenySetting of something other than "None"

The built-in owners role will have this permission by default. However, the built-in contributor role will not have this permission.

This change will affect all API versions.

We will update this issue with updates as the feature approaches release. Feel free to raise questions in the discussion below.

[snarkywolverine]

This change will be rolling out over the next 1.5 weeks or so. There are a few parts here:

1. The new permission is Microsoft.Resources/deploymentStacks/ManageDenySetting/action -- which should be available in all clouds.
2. The check for this permission should be rolled out by the end of next week to all regions in Public Azure. (Scope owners will have this permission by default).
3. Users with "Contributor" access will see their stacks with Deny Assignments start to fail starting next week. These users will need "Deployment Stacks Owner" permissions going forward -- that RBAC role will also be released next week.

[tomcperry]

Hi, I think I might have found a problem related to this.

When I attempt to create a stack at subscription level, and use --deny-settings-mode denyWriteAndRead, I get an internal service error message. When I repeat with --deny-settings-mode none, the deployment stack works as expected.

The full command I am using is:

az stack sub create --name "test-stack" --location "westeurope" --subscription "$SUB_ID" --deny-settings-mode denyWriteAndDelete --action-on-unmanage deleteAll --template-file test.bicep 

I get this result:

(DeploymentStackOperationFailed) Resource Provider has encountered an internal server error. Diagnostic information: timestamp '2024-05-13 20:08:56Z', request ID '7c16066f-b9f6-45fd-bc1e-fd069bf77aa6', request correlation ID 'f0db4da5-119f-4b10-a062-2afedda14e65'.
Code: DeploymentStackOperationFailed
Message: Resource Provider has encountered an internal server error. Diagnostic information: timestamp '2024-05-13 20:08:56Z', request ID '7c16066f-b9f6-45fd-bc1e-fd069bf77aa6', request correlation ID 'f0db4da5-119f-4b10-a062-2afedda14e65'.

If I change the --deny-settings-mode to none, it creates the stack with no problem.

My user principal does have the owner role, however, one thing that may be worth mentioning is that we are using PIM to activate the owner role. I have successfully activated the role, and logged out of the Az CLI and logged on again. I am not certain how to check that I have the specific permission listed above, but using the portal I can confirm that I have the owner role on our target subscription.

In case it is helpful, here is the output of az --version:

azure-cli                         2.60.0

core                              2.60.0
telemetry                          1.1.0

Extensions:
bastion                            0.3.0
reservation                        0.3.1
ssh                                2.0.3
virtual-wan                        1.0.0

Dependencies:
msal                              1.28.0
azure-mgmt-resource             23.1.0b2

Python location '/opt/az/bin/python3'
Extensions directory '/home/tom/.azure/cliextensions'

Python (Linux) 3.11.8 (main, Apr 24 2024, 04:14:09) [GCC 11.4.0]

Legal docs and information: aka.ms/AzureCliLegal

Your CLI is up-to-date.

I should add that this started happening during the last week. On Wednesday last week (8th May) it worked fine with the deny-settings

[snarkywolverine]

Hi @tomcperry - yes, we are aware of an issue with this change in West Europe. We expect to have it mitigated in the next couple of hours (if not sooner).

[snarkywolverine]

@tomcperry WEU should be working again. Thanks for reporting this.

[Splaxi]

Can confirm that having the Owner (RBAC) role directly on the subscription - unblocks you when you are hitting the is not authorized to perform action 'Microsoft.Resources/deploymentStacks/manageDenySetting/action' while deploying a stack at the subscription scope.

Thank you 🙏

[snarkywolverine]

@Splaxi - Just FYI, there is also a Stack-specific Owner role - Deployment Stack Owner, I believe - available in all clouds that can also provide the necessary permissions (if granting the owner role is not permissible). See #164 for some additional details.

[snarkywolverine]

This change has been released to all clouds and all regions.