Azure VNET Security

This exercise will demonstrate deployability of resources based on subnet status.

Create the variables file:

cp config/template.tfvars .auto.tfvars

Set your public IP address in the allowed_source_address_prefixes variable using CIDR notation:

# allowed_source_address_prefixes = ["1.2.3.4/32"]
curl ifconfig.io/ip

Create the keys:

mkdir keys && ssh-keygen -f keys/temp_rsa

Check for updated agent versions:

# Identify latest version of Network Watcher extension for Linux.
az vm extension image list --name 'NetworkWatcherAgentLinux' --publisher 'Microsoft.Azure.NetworkWatcher' --latest --location 'eastus2'

Create the base resources:

Note

Request might fail if there is already a Network Watched created for the region. Adapt accordingly.

terraform init
terraform apply -auto-approve

Network Monitor

To enabled advanced monitoring capabilities, such as the Connection Monitor, use the Network Watcher Agent.

This project already installs the agent by default.

You can enable the Connection Monitor from the Azure Monitor Insights section for the Network blade.

Azure VNET Subnet Delegation

The following subnets will be created within the VNET:

Subnet	Is empty?	Service Endpoint	Subnet Delegation
Subnet001	No	-	-
Subnet002	Yes	Microsoft.Storage	-
Subnet003	Yes	-	Microsoft.Sql/managedInstances
Subnet004	Yes	-	Microsoft.Web/serverFarms
Subnet005	Yes	-	-

The results are interesting when looking at Subnet003.

When integrating services to subnets, we get different outputs:

Service	Subnet 1	Subnet 2	Subnet 3	Subnet 4	Subnet 5
App Service	❌	✅	❌	✅	✅
SQL MAnaged Instance	❌	✅	✅	✅	✅

Requirements for App Service:

Requirements for SQL Managed Instance:

Application Security Group (ASG)

All network interfaces assigned to an application security group have to exist in the same virtual network that the first network interface assigned to the application security group is in. For example, if the first network interface assigned to an application security group named AsgWeb is in the virtual network named VNet1, then all subsequent network interfaces assigned to ASGWeb must exist in VNet1. You can't add network interfaces from different virtual networks to the same application security group.

Here're some commands to test ASGs.

Although not mentioned explicitly, you cannot use an ASG created in a different region.

# Creating in different regions to test compatibility

# You can add this one
az network asg create -g rg-test001 -n asg-test001-eastus2 -l eastus2

# You CANNOT add this one as it is from a different region
az network asg create -g rg-test001 -n asg-test001-brazilsouth -l brazilsouth

Service Tags

Verify the effectiveness of the Internet service tag via NSG.

Confirm the network resolution route:

# Verify that the IP is private (10.*.*.*)
dig stnsgflowlogs1238casdf.blob.core.windows.net

Confirm that normal internet route services are working:

# This should work
curl https://www.google.com

Test the connection via private route to the storage:

# This should fail
curl https://stnsgflowlogs1238casdf.blob.core.windows.net

If you enable the ASG permission, it is possible to allow the communication.

This demonstrates that the Internet tag is exclusively to public addresses and does affect virtual network connectivity.

---

Clean up the resources

Destroy the resources after using it:

terraform destroy -auto-approve