notScopes for subscriptions wildcard pattern

[riosengineer]

Hi team!

I have some policyAssignments that I only need to apply to production subscriptions but I am applying the scope at the parent management group. These assignments are monitoring/custom alert metrics. They need to auto-inherit any new subs that get created for production but not for the subsequent lower subs, e.g.

management_group <- policyAssignment applied to this scope
   somesub-dev-thing <- want to exclude this from the assignment
   somesub-test-thing <- and this
   somesub-prod-thing

We add this setup often for new applications. Therefore, adding individual sub IDs is not very feasible in the notScopes. I want to add a notScopes like:

  "scope": {
    "epac-prod": [
      "/providers/Microsoft.Management/managementGroups/mg_landing_zones"
    ]
  },
  "notScopes": {
    "epac-prod": [
      "/subscriptions/sub-dev*", <- doesn't seem to work 
      "/subscriptions/sub-tst*" , <- as above
      "/subscriptions/*/resourceGroups/rg-uks-dev*", 
      "/subscriptions/*/resourceGroups/rg-uks-tst*" 
    ]
  }
}

This way I can exclude these assignments from all subscriptions that are dev / test because they do not need these policyAssignments. It seems this works great for the resource group pattern, but it does not seem to work for the subscription level. I can manually add the subscription exclusions in the assignment in the Portal however.

Should I be approaching this in a different way?

EDIT: Also, I guess, this ask would apply to the policyExemptions too for ease of exemptions

[anwather]

Just a thought but why not add another management group under the assignment scope, and then add your dev/test subs under that and exclude the management group? Patterns aren't supported for subscriptions at this stage - we'd have to add it as a feature.

[riosengineer]

Unfortunately I wouldn't be able to go down that road. we have a landing zone MG and then many app specific MGs as a child under this, so each of those contain the dev/test/prod setup.

Thanks for replying. I just wanted to make sure I wasn't missing anything. I would love the feature naturally... 😄

I suppose without the wildcard support for subs, my portal changes would get overwritten on my next EPAC deployment anyway? @anwather

[anwather]

Thats correct. We can put this as a feature request though and get it done.

[riosengineer]

Thats correct. We can put this as a feature request though and get it done.

Awesome. Thank you 💪 edit: the exemptions support would be amazing too, so I can keep my compliance nice and green 🙃 @anwather

[apybar]

@riosengineer - The exemptions is something already on the roadmap I plan on working on before EOY.

See --> #687

[anwather]

@riosengineer - can you clone this repo and run from the scripts\deploy\Build-DeploymentPlans using the branch - feature/aw/issue828. I've made a change in there to test whether this would work. You will have to specify a subscription pattern as below:-

"scope": {
    "epac-prod": [
      "/providers/Microsoft.Management/managementGroups/mg_landing_zones"
    ]
  },
  "notScopes": {
    "epac-prod": [
      "/subscriptions/subscriptionsPattern/sub-dev*", 
      "/subscriptions/subscriptionsPattern/sub-tst*" , 
      "/subscriptions/*/resourceGroups/rg-uks-dev*", 
      "/subscriptions/*/resourceGroups/rg-uks-tst*" 
    ]
  }
}

It uses a -like to check the pattern against a subscription name so normal rules apply for wildcards. Run the plan and check the output to see if it correctly calculates the scope. Seems to work with my limited testing but if it is good for you I'll get some input from the team as to how we want to present it in the assignment JSON file.

[riosengineer]

@riosengineer - can you clone this repo and run from the scripts\deploy\Build-DeploymentPlans using the branch - feature/aw/issue828. I've made a change in there to test whether this would work. You will have to specify a subscription pattern as below:-

"scope": {
    "epac-prod": [
      "/providers/Microsoft.Management/managementGroups/mg_landing_zones"
    ]
  },
  "notScopes": {
    "epac-prod": [
      "/subscriptions/subscriptionsPattern/sub-dev*", 
      "/subscriptions/subscriptionsPattern/sub-tst*" , 
      "/subscriptions/*/resourceGroups/rg-uks-dev*", 
      "/subscriptions/*/resourceGroups/rg-uks-tst*" 
    ]
  }
}

It uses a -like to check the pattern against a subscription name so normal rules apply for wildcards. Run the plan and check the output to see if it correctly calculates the scope. Seems to work with my limited testing but if it is good for you I'll get some input from the team as to how we want to present it in the assignment JSON file.

Hey @anwather. Thanks for this. Is it this: https://github.com/Azure/enterprise-azure-policy-as-code/tree/feature/aw/issue831/ ?

As I don't see a branch with the issue 828 but I see the commit about subscriptionPatterns in 831. I did try with 831 cloned (using ./Scripts/Deploy/Build-DeploymentPlans.ps1, using my /Definitions folder but, to be honest, my output JSON seems the same to when I run it via the normal EPAC pwsh module I have installed (which I assume is running the current release version of Build-DeploymentPlans).

My notScopes is:

"notScopes": {
    "epac-prod": [
      "/subscriptions/subscriptionsPattern/sub-dev*", 
      "/subscriptions/subscriptionsPattern/sub-tst*" , 
      "/subscriptions/*/resourceGroups/rg-uks-dev*",
      "/subscriptions/*/resourceGroups/rg-uks-tst*"
    ]
  }
}

Here's some of the json output, looks like it is happily excluding the RGs as normal, but not sure what the sub pattern should look like, but it seems like it's not there, unless I am doing something wrong.

Any ideas?

[anwather]

Oops I made a mistake - can you please pull the latest commit and try again?

[riosengineer]

Oops I made a mistake - can you please pull the latest commit and try again?

Works great now! Thanks :)