Author : MD TAREQ HASSAN | Updated : 2021/12/27
Where to apply NSG
- NIC (network interface card)
- Subnet
Default NSG rules
- Azure creates default rules in each network security group that we create
- It is not possible to remove the default rules, but we can override them by creating rules with higher priorities
- https://docs.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview#default-security-rules
GatewaySubnet
- NSG on the GatewaySubnet is not supported
- Avoid associating a network security group (NSG) to the gateway subnet
- Associating a network security group to GatewaySubnet may cause your virtual network gateway (VPN & Express Route gateways) to stop functioning as expected
AzureFirewallSubnet
- Subnet level NSGs aren’t required on the AzureFirewallSubnet, and are disabled to ensure no service interruption
- If NSG is applied to AzureFirewallSubnet, Firewall might not work properly
- Azure Firewall is a managed service with multiple protection layers, including platform protection with NIC level NSGs (not viewable)
- https://docs.microsoft.com/en-us/azure/firewall/firewall-faq#are-network-security-groups--nsgs--supported-on-the-azurefirewallsubnet
ApplicationGatewaySubnet
- NSGs are supported on Application Gateway but there are some restrictions
- If you decide to block access to public IP of Application Gateway (described below):
- You need to use annotation for private IP while creating AGIC ingress (by default AGIC ingress is created for public ip)
- Annotation for private IP:
appgw.ingress.kubernetes.io/use-private-ip: "true"
Block access to public IP of Application Gateway
- Remove listener for public IP (using Azure Portal)
- Settings: Frontend IP configurations > Click on “public”
- “Associated listeners” > Click on listener
- Frontend IP: change to private > Save (might take some time)
- Do not perform other settings until saving opertaion is completed (otherwise removing listener from public IP might fail)
- Create network security group (NSG) and associate to
ApplicationGatewaySubnet
- NSG name:
nsg-appgwsubnet-hsystem-dev-japaneast
) - Add required inbound rules to NSG (see below)
- Keep default outbound rules (Application Gateway needs direct internet connection)
- Settings: Subnets > “+ Associate”
- NSG name:
Inbound rule - AllowGatewayManager
- Source: Service Tag
- Source service tag:
GatewayManager
- Source port ranges:
*
- Destination: Any
- Service: Custom
- Destination port ranges:
65200-65535
- Protocol: Any
- Action: Allow
- Priority: 100
- Name:
AllowGatewayManager
- Description: Allow traffic from GatewayManager
Inbound rule - AllowAzureLoadBalancer
- Source: Service Tag
- Source service tag:
AzureLoadBalancer
- Source port ranges:
*
- Destination: Any
- Service: Custom
- Destination port ranges:
*
- Protocol: Any
- Action: Allow
- Priority: 110
- Name:
AllowAzureLoadBalancer
- Description: Allow traffic from AzureLoadBalancer
Inbound rule - DenyInternet
- Source: Service Tag
- Source service tag:
Internet
- Source port ranges:
*
- Destination: Any
- Service: Custom
- Destination port ranges:
*
- Protocol: Any
- Action: Deny
- Priority: 1000
- Name:
DenyInternet
- Description: Deny incoming internet traffic
All NSG rules
SqlManagedInstanceSubnet
- NSG table must be created and attached to SqlManagedInstanceSubnet before provisioning Managed Instance (Azure Portal does it for you, in case of IaC you need to do it manually)
- NSG rules
- Managed Instance adds its necessay NSG rules for management traffic (service managed configurations)
- Azure Portal: creates additional NSG rules (i.e. “allow_tds_inbound”, “allow_redirect_inbound”) to allow traffic from same VNet and peered VNet
- IaC: you need to add required NSG rules to allow traffic from same VNet, peered VNet and on-premise
AKS Subnet
- No need to add NSG to AKS subnet
- Node pool VMSSs (Virtual Machine Scale Sets) live in Azure managed “
MC_xxx
” resource group and protected with NSG accordingly
PrivateEndpointSubnet
- As of January’2022, NSG for private endpoint is in preview
- Check general avaialability and attach NSG to PrivateEndpointSubnet if required
BastionSubnet
- Conclusion: NSG is not required
- Explanation:
- Azure Bastion is a fully managed platform PaaS service from Azure that is hardened internally to provide you secure RDP/SSH connectivity. You don’t need to apply any NSGs to the Azure Bastion subnet
- Link: https://docs.microsoft.com/en-us/answers/questions/531182/nsg-required-for-bastion-subnet.html
DmsSubnet
- DMS: Data Migration Service (Azure Data Migration Service)
- NSG can be applied to DmsSubnet, but need to open certain ports and protocols
- See: https://docs.microsoft.com/en-us/azure/dms/pre-reqs#prerequisites-common-across-migration-scenarios
DatabricksSubnet
- Add NSG rules if required (Databricks-managed NSG rules will be added automatically)
- Use same NSG for both
DatabricksPublicSubnet
andDatabricksPrivateSubnet
- See: