Project Overview
This project documents the foundational networking layer that most Azure workloads sit on top of: a Virtual Network (VNet), address-space planning via subnets, and traffic control through Network Security Groups (NSGs). It closes the loop by provisioning a Linux virtual machine into that network and connecting to it over SSH — proving the network, security rules, and compute layer all work together end to end.
Skills demonstrated: VNet and subnet design (CIDR planning), Network Security Group configuration, inbound/outbound rule prioritization, custom SSH access rules, VM provisioning with SSH key-pair authentication, NIC-to-subnet association, public IP assignment, secure remote access verification.
Screen-by-Screen Breakdown
Screen 1 — Creating the Virtual Network
Provisioned a new Virtual Network (KOLAVN_RG) inside a dedicated resource group, establishing the foundational address space that all subnets and resources in this project would live inside.
Steps:
Navigate to Virtual networks → Create virtual network.
Under Project details, create a new resource group (KOLAVN_RG).
Under Instance details, name the virtual network and select the region (West US).
Move to the IP addresses tab to configure the address space.
Screen 2 — Configuring the First Subnet
Defined the first subnet (kola_subnet) within the VNet's address space, setting a /24 range to segment part of the network for later resource placement.
Steps:
On the IP addresses tab, click Add a subnet.
Name the subnet (kola_subnet).
Confirm the IPv4 address range (10.0.0.0/16) and set the starting address (10.0.1.0).
Set the subnet size (/24, 256 addresses).
Click Add, then proceed to Review + create.
Screen 3 — Confirming the VNet Deployment
Verified the Virtual Network deployment completed successfully before moving on to add further subnets and security configuration.
Steps:
Wait for the deployment to finish.
Confirm the green "Your deployment is complete" status.
Click Go to resource to open the new VNet.
Screen 4 — Reviewing Subnets Before Adding Security
Checked the VNet's subnet list after adding a second subnet (kola_sub2), noting that neither subnet yet had a Network Security Group attached — flagging the next task.
Steps:
Open the VNet and go to Settings → Subnets.
Review the subnet list: names, IPv4 ranges, and available IPs.
Note the Security group column is empty for both subnets — this is the gap to close next.
Screen 5 — Navigating to Network Security Groups
Used the global Azure search to jump directly to the Network Security Groups service, in preparation for creating and attaching a security boundary to the subnets.
Steps:
Click the top search bar in the Azure Portal.
Search "network security group."
Select Network security groups from the Recent services list.
Screen 6 — Reviewing the Network Security Group's Default Rules
Opened the newly associated NSG (kolaweb) and reviewed its default inbound and outbound rules — the baseline Azure applies automatically (allow VNet traffic, allow Azure Load Balancer, deny everything else by default).
Steps:
Open the NSG resource (kolaweb).
Review Essentials: resource group, location, subscription.
Review the default Inbound Security Rules (AllowVnetInBound, AllowAzureLoadBalancerInBound, DenyAllInBound) and Outbound Security Rules.
Navigate to Settings → Inbound security rules to add a custom rule.
Screen 7 — Opening Inbound Security Rules
Confirmed the current inbound rule set before adding a custom rule to explicitly allow SSH traffic to the VM that would later sit behind this
NSG.
Steps:
Go to Settings → Inbound security rules.
Review existing default rules and priorities.
Click + Add to create a new custom rule.
Screen 8 — Adding a Custom SSH Inbound Rule
Created a dedicated inbound rule permitting SSH traffic (TCP port 22), explicitly named and documented so the rule's purpose would be clear to anyone auditing the NSG later.
Steps:
In Service, select SSH (auto-fills TCP port 22).
Set Protocol to TCP and Action to Allow.
Set Priority (e.g. 100) — lower numbers are evaluated first.
Name the rule (SSH_NETWORK) and add a description ("Connect SSH network").
Click Add to save the rule.
Screen 9 — Starting Virtual Machine Creation
With the network and security layer in place, began provisioning a virtual machine to deploy into the secured subnet.
Steps:
Navigate to Virtual machines under Compute infrastructure.
Confirm no existing VMs are listed.
Click + Create to start the VM creation wizard.
Screen 10 — Configuring VM Basics
Configured the core VM settings: name, region, a cost-efficient Ubuntu image and size, and SSH public-key authentication instead of a password for secure, auditable access.
Steps:
Set Virtual machine name (KOLA-VM) and Region (West US).
Choose the Image (Ubuntu Server 24.04 LTS) and Size (Standard_D2s_v3).
Set Authentication type to SSH public key.
Set the Username (azureuser) and Key pair name (KOLA-VM_key).
Set Public inbound ports to None (access will be governed by the NSG rule instead).
Screen 11 — Attaching the VM to the Secured Subnet
Connected the VM's network interface to the previously created VNet and subnet, assigned a new public IP, and applied the NSG containing the SSH rule — tying the whole project together at the networking layer.
Steps:
Go to the Networking tab.
Confirm Virtual network (KOLAVN_RG) and select Subnet (kola_subnet, 10.0.1.0/24).
Confirm a new Public IP will be created.
Set NIC network security group to Basic (or Advanced to select the custom NSG directly).
Leave accelerated networking enabled for better throughput, then click Review + create.
Screen 12 — Validating and Generating the SSH Key Pair
Passed validation on the VM configuration and generated a new SSH key pair, downloading the private key — the only copy, since Azure does not retain it after generation.
Steps:
Confirm "Validation passed" at the top of the Review + create tab.
Review the configuration summary (resource group, VM name, region, security type).
In the Generate new key pair dialog, click Download private key and create resource.
Store the downloaded .pem file securely — it cannot be re-downloaded later.
Screen 13 — Connecting to the VM via Native SSH
Used the Azure Portal's built-in Connect blade to generate and run the correct SSH command, pointing to the downloaded private key, to establish a secure remote session into the new VM.
Steps:
Open the VM and go to Connect → Connect.
Select Native SSH, and confirm the destination VM's public IP and port (22).
Provide the local path to the downloaded private key file.
Copy the generated SSH command (ssh -i "" azureuser@).
Run it in a local terminal to connect.
Top comments (0)