Deployment Stacks - DenyWriteAndDelete allows modification of Network Security Group rules

[lukemurraynz]

Bicep version Bicep CLI version 0.20.4 (c9422e016d)

Describe the bug When testing Azure Deployment Stacks, I deployed a Virtual Network with Network Security Groups with 'DenyWriteAndDelete', although Deployment Stacks, prevented me from unassociating the NSG from the subnet. I was able to add NSG rules and remove NSG rules that were deployed as part of my initial deployment.

To Reproduce Steps to reproduce the behavior:

Deploy Virtual Network, with Subnet and NSG. Add in Inbound Security Group Delete Rule added.

Note:

Bicep file: https://gist.github.com/lukemurraynz/ec4ae1aa83b923a8a16bdc1b5494d618

PowerShell: $RGName = 'rg-network' $DenySettings = 'DenyWriteAndDelete' $BicepFileName = 'main.bicep' $DeploymentStackName = 'NetworkProd'

Set-AzResourceGroupDeploymentStack -Name $DeploymentStackName -ResourceGroupName $RGName -TemplateFile $BicepFileName -DenySettingsMode $DenySettings -DeleteResources -Verbose

Additional context

[sqlkabouter]

Similar issue with roleAssignments. I can create and delete roleAssignments through the Azure portal on resources deployed and managed by the stack. I can create a separate issue to track this issue if that helps.

[snarkywolverine]

@sqlkabouter I would expect role assignments to be created on managed resources if ApplyToChildScopes is false. Can you try setting that property to true if you haven't already? If you still have problems, a new issue would make it easier to investigate.

[snarkywolverine]

@lukemurraynz Can you please share the correlation ID of the most recent stack update? I'm also looking to clarify your comments:

Deployment Stacks prevented me from unassociating the NSG from the subnet This sounds like it's working as expected.

I was able to add NSG rules and remove NSG rules that were deployed as part of my initial deployment. How are you adding/removing NSG rules? If you're updating/doing another PUT on the NSG with the new configuration, this should be blocked by the deny assignment and needs further investigation.

However, if you're performing a PUT/DELETE on a Microsoft.Network networkSecurityGroups/securityRules child resource, then that action would only be blocked by a deny assignment if ApplyToChildScopes is true.

[lukemurraynz]

Thanks for your response; it is possible that 'ApplyToChildScopes' is the main issue here (as I didn't have it specified).

In my test, I was able to add an NSG rule via the Azure Portal (note the original NSG rules are deployed via the Bicep template) - which is what I thought of:

I wrote a blog article on Deployment Stacks (which is how I also deployed and tested this, including the Bicep), so any feedback is great and I can amend: https://luke.geek.nz/azure/Azure-Bicep-Deployment-with-Deployment-Stacks/

Where can I find the correlation ID (the IDs I am thinking of have the subscription ID etc in it)?

[sqlkabouter]

@sqlkabouter I would expect role assignments to be created on managed resources if ApplyToChildScopes is false. Can you try setting that property to true if you haven't already? If you still have problems, a new issue would make it easier to investigate.

Thanks. Adding the option deny-settings-apply-to-child-scopes has solved my issue. This is the code I'm using the deploy:

az stack group create `
  --name 'deployment-stack' `
  --resource-group 'rg-deployment-stack' `
  --template-file 'deploymentstack.bicep' `
  --deny-settings-mode 'DenyWriteAndDelete' `
  --deny-settings-apply-to-child-scopes `
  --delete-resources

I'm not specifying any exclusions to the deny option with --deny-settings-excluded-principals currently so I did notice some issues with not being able to deploy to my own stack anymore. I had to add myself to the exclusions and then run the deployment twice. The first time the deployment failed with write access denied on my principal but it was succesfully added to the exclusions making the next deployment work.

Just a random thought but wouldn't it work better if the principal that did the initial deployment was added to the exclusions by default?

[snarkywolverine]

@lukemurraynz Hmm, apparently the correlation ID isn't as easy to retrieve as I thought, and that's something we'll address. The easiest way right now is to pull it from the underlying deployment.

@sqlkabouter Stacks was designed so that users shouldn't need to exclude their own principals for future deployments -- as long as the resource is managed by the same stack, it should work. It sounds like that's not happening though - can you open a bug for that? Hopefully with a correlation ID?

[snarkywolverine]

@lukemurraynz @sqlkabouter I'm going to close this incident - I think all of the issues have been addressed at this point, with the exception of 'redeploying my own stack', which is being tracked by another issue. At this point, we believe the issue is related only to role assignments; but if you find another resource type that has a failure, Please share it in issue #123.