Policies incompatible with Terraform

[krowlandson]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Versions

terraform: all

azure provider: all

module: all

Description

Due to the way the azurerm provider works, the following Policy Definitions are incompatible with Terraform:

• Deny-Subnet-Without-NSG
• Deny-Subnet-Without-UDR

Steps to Reproduce

1. Create a deployment where these policies are assigned at a specific scope.
2. Place a Subscription under this scope.
3. Try to create a Virtual Network with Subnets missing NSG and UDR configurations (note that even if you add these using the approach available by Terraform, the deployment fails)

Screenshots

Additional context

[krowlandson]

Considering the option to set these to "Audit" as default effect in the Terraform module.

Does anyone have thoughts on how best to approach this?

Also thinking this could be developed alongside updating the module to simplify the approach for controlling whether DINE policies are enabled or not, in alignment with the guidance recently published by @jtracey93: Adopt policy-driven guardrails

[nikolai-fra]

We did set these to "Audit" to workaround this issue.

To do this we used a custom archetype_extension and set the required parameter:

File lib/archetype_extension_es_landing_zones.tmpl.json

{
  "extend_es_landing_zones": {
    "policy_assignments": [],
    "policy_definitions": [],
    "policy_set_definitions": [],
    "role_definitions": [],
    "archetype_config": {
      "parameters": {
        "Deny-Subnet-Without-Nsg": {
          "effect": "Audit"
        }
      },
      "access_control": {}
    }
  }
}

Probably we could set this parameter as default in the archetype_definition here?

In addition a mention in the docs? Then it would be easy for users to customize the effect again ...

But this would be rather a patch than your proposed changes from the linked CAF article.

Did you asked how to fix the root cause? Sry I'm no help here.

[jtracey93]

Thanks @nikolai-fraport for sharing your insights here, that's certainly a good way to do this 👍

Myself & @krowlandson have just been discussing this and have agreed that we will provide guidance similar to what you have shared above in a Wiki docs page, adding to what we say here already https://github.com/Azure/terraform-azurerm-caf-enterprise-scale/wiki/%5BUser-Guide%5D-Getting-Started#additional-considerations-when-deploying-landing-zone-resources-with-terraform

Likely this section will become a new Wiki page on its own and the "Getting Started" page will be left as just that.

We will also be bringing this back up with the relevant engineering teams internally to work out a better approach than effectively changing the policies desired effect.

• [ ] Move this https://github.com/Azure/terraform-azurerm-caf-enterprise-scale/wiki/%5BUser-Guide%5D-Getting-Started#additional-considerations-when-deploying-landing-zone-resources-with-terraform to it's own new page in the wiki
  • [ ] Add example of how to change effect from deny to audit in the doc also
  • [ ] Also include UDR policy as well

[jtracey93]

Trigger ADO Sync