feat(new): Added Azure.VNET.NAT

[BenjaminEngeset]

PR Summary

Fixes #3003

Added Azure.VNET.NAT.

PR Checklist

• [x] PR has a meaningful title
• [x] Summarized changes
• [x] Change is not breaking
• [x] This PR is ready to merge and is not Work in Progress
• Rule changes
  • [x] Unit tests created/ updated
  • [x] Rule documentation created/ updated
  • [x] Link to a filed issue
  • [x] Change log has been updated with change under unreleased section
• Other code changes
  • [ ] Unit tests created/ updated
  • [ ] Link to a filed issue
  • [ ] Change log has been updated with change under unreleased section

[BenjaminEngeset]

Ready for review @BernieWhite.

The rule is initially created for used-managed virtual machines, but there are other services that can take advantage of this as well.

[BernieWhite]

@BenjaminEngeset this one is a little more nuanced.

When a customer starts deploying multiple workloads for most cases they should be thinking about using a VWAN or hub and spoke network with a central Azure Firewall or NVA for controlling east/ west and north/ south traffic, following something like the cloud adoption framework. As a result, every subnet shouldn't have a NAT gateway attached. Realistically the number of internet egress points should be minimized.

You could say that anything in the VNET hub should have a NAT gateway, but even then, there is cases when this is not ideal.

• NAT Gateway is zonal, so you should deploy one in each AZ you deploy to, but with something like Azure Firewall that supports zone redundancy deploying a single NAT gateway (only one can be deployed in a subnet) could decrease the availability of outbound traffic if the zone that failed was the same as the NAT gateway.
• In the NVA configuration, there is often a private and public subnet used in-front and behind the NVA instances. The NAT gateway should only be deployed on the public subnet.

So, I'm not sure if we can reliability detect the cases from code the cases that should use a NAT gateway.

Did you have any further thoughts on this?

[BenjaminEngeset]

@BenjaminEngeset this one is a little more nuanced.

When a customer starts deploying multiple workloads for most cases they should be thinking about using a VWAN or hub and spoke network with a central Azure Firewall or NVA for controlling east/ west and north/ south traffic, following something like the cloud adoption framework. As a result, every subnet shouldn't have a NAT gateway attached. Realistically the number of internet egress points should be minimized.

You could say that anything in the VNET hub should have a NAT gateway, but even then, there is cases when this is not ideal.

• NAT Gateway is zonal, so you should deploy one in each AZ you deploy to, but with something like Azure Firewall that supports zone redundancy deploying a single NAT gateway (only one can be deployed in a subnet) could decrease the availability of outbound traffic if the zone that failed was the same as the NAT gateway.
• In the NVA configuration, there is often a private and public subnet used in-front and behind the NVA instances. The NAT gateway should only be deployed on the public subnet.

So, I'm not sure if we can reliability detect the cases from code the cases that should use a NAT gateway.

Did you have any further thoughts on this?

I agree with you @BernieWhite and I am truly grateful for your honest feedback.

What I can do instead is to create a new issue and new rule regarding AzureFirewallSubnet that is towards mitigating port exhaustion and less administrative overhead, so zonal-deployed firewalls can use a NAT gateway What do you think about that? There is official documentation for this.

https://learn.microsoft.com/en-us/azure/firewall/integrate-with-nat-gateway

[BernieWhite]

@BenjaminEngeset this one is a little more nuanced. When a customer starts deploying multiple workloads for most cases they should be thinking about using a VWAN or hub and spoke network with a central Azure Firewall or NVA for controlling east/ west and north/ south traffic, following something like the cloud adoption framework. As a result, every subnet shouldn't have a NAT gateway attached. Realistically the number of internet egress points should be minimized. You could say that anything in the VNET hub should have a NAT gateway, but even then, there is cases when this is not ideal.

• NAT Gateway is zonal, so you should deploy one in each AZ you deploy to, but with something like Azure Firewall that supports zone redundancy deploying a single NAT gateway (only one can be deployed in a subnet) could decrease the availability of outbound traffic if the zone that failed was the same as the NAT gateway.
• In the NVA configuration, there is often a private and public subnet used in-front and behind the NVA instances. The NAT gateway should only be deployed on the public subnet.

So, I'm not sure if we can reliability detect the cases from code the cases that should use a NAT gateway. Did you have any further thoughts on this?

I agree with you @BernieWhite and I am truly grateful for your honest feedback.

What I can do instead is to create a new issue and new rule regarding AzureFirewallSubnet that is towards mitigating port exhaustion and less administrative overhead, so zonal-deployed firewalls can use a NAT gateway What do you think about that? There is official documentation for this.

https://learn.microsoft.com/en-us/azure/firewall/integrate-with-nat-gateway

Yes #3005 #3006 is a good idea.