Latest azure/alz provider (0.10.1) breaks avm-ptn-alz

[phx-tim-butters]

The following change to the azure/alz provider fundamentally changes the policy and rbac assignment manipulations - it's broken the latest version of the avm plt lz (0.4.1):

https://github.com/Azure/terraform-provider-alz/commit/e342112c591bd3148a4935e946e87495e3c33ace

If any manipulation exists, it fails (for example - policy_assignments_to_remove)

I'm working around this by latest version 0.9.2 at my root and throwing it to the module - but this avm will break by default as the module has no version constraint for azure/alz

[matt-FFFFFF]

Hey thanks for reporting - you are quite right!

[matt-FFFFFF]

PR linked

[phx-tim-butters]

Thanks. Looking at the changes, is the option to remove a policy assignment from an archetype being retained ?

[matt-FFFFFF]

Hey,

You can create a local library and add an archetype_override file. This will create a copy of a base archetype and then add/remove items as specified.

Schema: https://github.com/Azure/Azure-Landing-Zones-Library/blob/main/schemas/archetype_override.json

Example:

{
  "base_archetype": "root",
  "name": "root_override",
  "policy_assignments_to_add": [
    "override-policy-assignment"
  ],
  "policy_assignments_to_remove": [
    "test-policy-assignment"
  ]
}

[matt-FFFFFF]

Also, please use provider version 0.10.2 as a minimum - I found a particularly horrible bug

[phx-tim-butters]

Hey Matt,

I've spent a little while trying to understand how your override mechanics work. I can see the Schema in the definitions, and I don't think there's any specifics on location of the override file within the custom lib folder - but the above isn't seemingly working for me.

I don't know Go, but I've tried to interpret the provider code to see where an override file is taken into account and I cannot see it.

Would you be able to elaborate anything further than the schema as per above?

Having tried the following (I have a custom "Set-CIS2-0-0" file in the Assignments custom lib):

{ "base_archetype": "root", "name": "root_override", "policy_assignments_to_add": [ "Set-CIS2-0-0" ], "policy_assignments_to_remove": [ ] }

Using the "root" base_archetype in the module callout doesn't include the Set-CIS-2-0-0 assignment. I did maybe think it's now called the root_override archetype, but using that in the module callout returns "Base archetype not found".

Any help would be appreciated.

[matt-FFFFFF]

Hi!,

Much of the "brains" of the provider is actually in a go module called alzlib: Azure/alzlib.

You can see the code that processes the override archetypes here:

https://github.com/Azure/alzlib/blob/ddacf52299af79b58e46becf5405dde07dc71d60/alzlib.go#L533-L534

If I understand you correctly you'd like to include an additional assignment in the root archetype?

Firstly you need the definition. If this is built-in then there is nothing to do. If this is custom then you need to add the policy(set)definition_*.json file to your custom lib.

Next you need to create a policyassignment*.json file.

You do not need to worry about the management group portion of the resource id, as the provider will re-write this for you.

Next you need to create a archetypeoverride*.json file and add the assignment name to the policy_assignments_to_add array.

Then when you use the module, instead of assigning the root archetype, you should assign the name of the override archetype instead/

[phx-tim-butters]

Hey Matt, Makes perfect sense - thank you. And is exactly what we were doing with the CAF Enteprrise Scale module. I think i've come to the conclusion it's using a relatively similar process to that.

One thing I've noted, is that the Default block in the alz_archetype - when it contains a default Log Analytics Workspace Id, there is a failure - as the legacy VM and VMSS Azure Monitor assignments try and put the log id on a parameter called LogAnalytics_1 - but the parameter is no where to be seen on the newer policy definition.

Error being;

Error: creating Scoped Policy Assignment (Scope: "/providers/Microsoft.Management/managementGroups/tb-platform-dev" │ Policy Assignment Name: "Deploy-VM-Monitoring"): unexpected status 400 with error: UndefinedPolicyParameter: The policy assignment 'Deploy-VM-Monitoring' has the parameter(s) 'logAnalytics_1' which are not defined in the policy definition '924bfe3a-762f-40e7-86dd-5c8b95eb09e6'. │ │ with module.alz_archetype_platform.azurerm_management_group_policy_assignment.this["Deploy-VM-Monitoring"], │ on .terraform\modules\alz_archetype_platform\main.tf line 88, in resource "azurerm_management_group_policy_assignment" "this": │ 88: resource "azurerm_management_group_policy_assignment" "this" { │ creating Scoped Policy Assignment (Scope: "/providers/Microsoft.Management/managementGroups/tb-platform-dev" │ Policy Assignment Name: "Deploy-VM-Monitoring"): unexpected status 400 with error: UndefinedPolicyParameter: The policy assignment 'Deploy-VM-Monitoring' has the parameter(s) 'logAnalytics_1' which are not defined in the policy definition │ '924bfe3a-762f-40e7-86dd-5c8b95eb09e6'.

[matt-FFFFFF]

Hi!

Yes I noticed this too.

It's a result of us not completing all the tasks on our road to v1.0.

The old default mappings are buried in alzlib, however the policies have been updated since and have new inputs.

This results in alzlib adding a parameter to the assignment that doesn't exist any more.

At the moment I've created an override that excludes these policies from landing zones and platform.