-
Notifications
You must be signed in to change notification settings - Fork 745
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extension resource Symbolic name for Resource that does not yet exist #8652
Comments
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:-
Our options are either
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' = { 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. |
Bicep version
06.10.61
Describe the bug
This might not be a bug as such. We have a Policy that denies the creation of an NSG if it allows access to the Internet, however we need to create just such a policy and security are happy for us to put in a Policy Exemption. However within bicep to deploy an Extension Resource (policyExemption) we need a symbolic name referencing an instance of the resource (NSG). This would then create a dependency between the NSG and the policyExemption, and as the NSG will be denied if the policyExemption is not deployed we hit a blocking issue.
To Reproduce
Create and Assign Policy that blocks NSG's that allow AllInternet rule
Create NSG - blocked
Additional context
Ideally we would be able to refer to a resource Id within the Extension Resource Scope, but this is not allowed within bicep.
The text was updated successfully, but these errors were encountered: