How can we improve Azure Governance?

Azure Policy - Support for RegEx in Match Conditions

Right now, the "Match" and "notMatch" conditions only support # for digit placeholders and ? for letters. This is okay, but it would be much more useful to support regex expressions. This would needed for define complex naming policies and tagging standards.

53 votes
Sign in
(thinking…)
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

DanM shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

10 comments

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • Dieter Wijckmans commented  ·   ·  Flag as inappropriate

    For your reference but also to be notified when there's an update.

    (?=.{0,15}$)((dls)[a-z]{3}[a-z]{5}(weu|scu|sea)(p|u|t|d|s))

  • Anonymous commented  ·   ·  Flag as inappropriate

    Basic regex pattern matching functionality is urgently required to enable proper enforcement of tags and naming conventions:
    * character classes / sets - [a-z0-9]
    * anchors - ^ $
    * alternation - abc|def|hij
    * grouping - ()
    * repetition - ? + * {n} {n,m}

    Thanks

  • Chris Lewis commented  ·   ·  Flag as inappropriate

    We use Management Groups, and I'd love some simple matches like "all subscriptions in a Management Group"

  • Marlo Bell commented  ·   ·  Flag as inappropriate

    Need to track App or IT Service ID in tags. Current implementation isn't sophisticated enough to be a good enforcer. ???-#### doesn't work because it doesn't control the prefix and the number on the end isn't always 4 digits.

    Examples:
    APP-12
    APP-123
    APP-1234
    SVC-13
    SVC-134
    SVC-1345

  • Brooks Vaughn commented  ·   ·  Flag as inappropriate

    We need more robust pattern matching. RegEx would work but in-lieu of that, then at least support what PowerShell supports.

    Why have Like with no support for many wildcards?
    Why have Match with no wildcards?

    I need something to support a rule where only UDR names that Match "PZI-G???-?-UDR-SLBR-*" are allowed:
    "not": {
    "field": "Microsoft.Network/virtualNetworks/subnets[*].routeTable.id",
    "notLike": "/subscriptions/*/resourceGroups/*/providers/Microsoft.Network/routeTables/PZI-G???-?-UDR-SLBR-*"
    }

  • Marcio Parente commented  ·   ·  Flag as inappropriate

    I'm trying to apply the following regex expression and no success.
    [a-z0-9]{1,10}mgd-(?:sb|dv|ts|rt)-[a-z0-9]{1,5}-(?:aes|ase|usc|use|use2|usw|uscn|uscs|eun|euw|jpw|jpe|brs|aue|aus|ins|inc|inw|cac|cae|uks|ukw|uscw|usw2|korc|kors|frc|frs)-rg-[0-9]{3}

  • Jan commented  ·   ·  Flag as inappropriate

    One would expect regex when it is named match.
    Current options cannot be used to match our naming standard. At least more complex conditions needed, for example multiple asterisks.
    But why invent something new, when there is a good and relative standard way of doing this (already supported by .net).

  • Steve Keeler commented  ·   ·  Flag as inappropriate

    Please consider implement basic regular expression pattern matching. If ReDoS is a concern, then limit so extensions such as back-tracking not implemented. I have multiple customers requesting this functionality.

  • Nick C commented  ·   ·  Flag as inappropriate

    I second this idea. Either allow more complex conditions, or allow regular expressions. Even allowing two wildcards within a 'like' condition would be enormously helpful. Right now, enforcing naming policy is cumbersome.

Feedback and Knowledge Base