[Bug Report]: Event Hub namaspace network ruleset trustedServiceAccessEnabled logic is not correct

[jachin84]

Describe the bug

The networkRuleSets in https://github.com/Azure/ResourceModules/blob/58691e44109c5991c29f5345944b3253be920a58/modules/event-hub/namespace/network-rule-set/main.bicep seem to have incorrectly logic.

resource networkRuleSet 'Microsoft.EventHub/namespaces/networkRuleSets@2022-01-01-preview' = {
  name: 'default'
  parent: namespace
  properties: {
    publicNetworkAccess: publicNetworkAccess
    defaultAction: publicNetworkAccess == 'Disabled' ? null : (!empty(ipRules) || !empty(virtualNetworkRules) ? 'Deny' : defaultAction)
    trustedServiceAccessEnabled: publicNetworkAccess == 'Disabled' ? null : trustedServiceAccessEnabled
    ipRules: publicNetworkAccess == 'Disabled' ? null : ipRules
    virtualNetworkRules: publicNetworkAccess == 'Disabled' ? null : networkRules
  }
}

The snippet above forces trustedServiceAccessEnabled to be null when publicNetworkAccess is set to "Disabled". This is incorrect. When using Private Endpoints this is the exact configuration that you need.

{
    "id": "/subscriptions/blah/resourcegroups/rg-1/providers/Microsoft.EventHub/namespaces/evtns-t-01/networkrulesets/default",
    "name": "default",
    "type": "Microsoft.EventHub/Namespaces/NetworkRuleSets",
    "location": "australiaeast",
    "properties": {
        "publicNetworkAccess": "Disabled",
        "defaultAction": "Allow",
        "virtualNetworkRules": [],
        "ipRules": [],
        "trustedServiceAccessEnabled": true
    }
}

To reproduce

Deploy https://github.com/Azure/ResourceModules/blob/58691e44109c5991c29f5345944b3253be920a58/modules/event-hub/namespace/network-rule-set/main.bicep using:

• publicNetworkAccess = 'Disabled'
• trustedServiceAccessEnabled = true

Code snippet

No response

Relevant log output

No response

[AlexanderSehr]

Hey @jachin84, thanks for the issue and please excuse the late reply. I agree with your statement. As the module is not migrated to AVM yet, it should also be fixed in CARML as is. We'll see to get it in, thank you :)

[AlexanderSehr]

@eriqua - it has been a while, but the original addition of the entire feature happened in a PR you contributed. It would hence be cool to know if something would come to mind that we're not considering. I'll implement the change now regardless and then we can ever merge it or not. :)