Bug: Asterisk ‘*’ is causing issue when passed as a value for destinationPortRange in NetworkSecurityGroupsSecurityRule

[nishant221]

Version of Azure Service Operator

mcr.microsoft.com/k8s/azureserviceoperator:v2.8.0

Describe the bug

According to NetworkSecurityGroupsSecurityRule , asterisk ‘*’
should be allowed as a value for destinationPortRange. But when the same is passed it's causing following error:

To Reproduce
Steps to reproduce the behavior:

• Pass following objects to ASO via kubectl

apiVersion: resources.azure.com/v1api20200601
kind: ResourceGroup
  name: test-rg
spec:
  azureName: test-rg
  location: eastus2
---
apiVersion: network.azure.com/v1api20201101
kind: NetworkSecurityGroup
metadata:
  name: nsg-test
spec:
  location: eastus2
  owner:
    name: test-rg
---
apiVersion: network.azure.com/v1api20201101
kind: NetworkSecurityGroupsSecurityRule
metadata:
  name: nsg-test-0
spec:
  azureName: test_rule
  owner:
    name: nsg-test
  priority: 2000
  sourcePortRange: "*"
  destinationPortRange: "*"
  sourceAddressPrefix: "VirtualNetwork"
  destinationAddressPrefix: "*"
  access: Deny
  protocol: "*"
  direction: Outbound
  description: Deny egress connections by default

Expected behavior
NSG should be created with required rules.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[matthchr]

This looks to me like an issue with a particular Azure policy applied to your subscription.
If it is, you should be able to see the same error by trying to create the NSG Rule via az cli or ARM template as well.

You likely need to track down the owner of the policy, as the fundamental problem looks like the policy assumes that this field will always be an integer when in fact it can be * as well. You can likely do this using the Azure portal by examining the policies that apply to this subscription and finding the one mentioned in the error message.

See Azure/azure-policy#396 which is another user with a similar issue.

This isn't related to ASO - will leave this issue open for a bit in case you have any other questions and then will close this.

[matthchr]

Closing this as we haven't heard anything and believe the issue is likely not with ASO.