Can you share more details/code samples about how the policy exemption needs to be expressed in bicep? I'm not following where you are blocked

Here is the workflow:-

1. Azure Policy that blocks NSG's being created that allow access to the Internet
2. Requirement to deploy a Checkpoint CloudGuard system on the boundary that requires an NSG that allows access to the Internet.

Our options are either

1. Disable our Security Policies whilst the Checkpoint deployment is performed, and each time an update is required.
2. Deploy a Policy Exception for the one NSG that will break the policy.

As both options will require Policy Admin requirements, we would prefer option 2 as that would not open up a security hole every time we deploy. All our deployments run with the appropriate RBAC, and this SPN is secured via a different mechanism to reduce other pipelines utilizing it.

However to deploy a policy exemption in bicep the definition starts with

resource symbolicname 'Microsoft.Authorization/policyExemptions@2020-07-01-preview' = {
name: 'string'
scope: resourceSymbolicName

notice the scope: resourceSymbolicName, this would be the NSG that we would like to deploy. However if we use the NSG's symbolic name this puts a dependency within the final ARM template so that the policy exemption is deployed after the NSG, which is refused by the very policy. Bicep does not allow the scope to be anything but the symbolic name.

Again we could put the Policy Exemption on the resource group, but we are attempting to keep the Policy Exemptions as specific as possible.

I understand this is an edge case, but its also the very reason for Policy Exemptions.

Right now we are utilizing strategy 1, disabling the Policy during the deployment but we are not happy with this.

I see. I don't see this as a bicep issue, as you would have the same problem no matter what tool you are using. TBH, I'm struggling to understand how this would work. It is impossible to create an extension resource that extends a resource that doesn't exist. I'm going to share this with the policy team and see if they have any ideas or have come across the scenario.

Thanks for sharing your scenario-- we have related scenarios that have come up on our radar. Do these NSGs differ in configuration in any way from an NSG that would be denied-- for example, do you have a particular naming convention that you apply for these NSG resources being created?

@nehakulkarni123 There is nothing special about our naming convention, roughly following that MS best practice. We would be hesitant to use names or tags for an exclusion as this could open up a potential hole in the policy. All our other policy exemptions in this area are currently based on excluding the resource group (things like VM images etc), but as this is a PCI environment we need to lock down NSG's as far as possible.

Right now we disable the Policy Assignment, perform our deployment using Azure DevOps and Bicep as the base, and then re-enable the Policy Assignment so we will get notifications of any other exceptions. Whilst this minimizes the time we are not protected by the Policies it does ensure we are notified in the case of an exception, so better then not having the policy but still a potential for manual intervention.