Deploy an Azure Linux VM with NSG and managed identity
Deploy a private Ubuntu 24.04 LTS VM with Trusted Launch, encryption at host, an explicit NSG, no public IP and a least-privilege system-assigned managed identity, then prove network, identity, patch and recovery controls.
Create an operational Azure Linux host whose boot chain, network exposure, workload identity and recovery behavior are explicit, verifiable and maintainable without embedded credentials.
- Azure CLI 2.88.0
- Ubuntu Server 24.04 LTS
- Azure Virtual Machines Generation 2
- Azure context Approved tenant, subscription, Region, resource naming, quota, policy, cost owner and short-lived deployment role.
az account show --output jsonc - Private administration Azure Bastion, VPN, ExpressRoute or another approved private SSH path exists and has a separate access and logging review.
- Network plan VNet and subnet prefixes are checked against peering, on-premises, VPN, container and private-endpoint ranges.
- Workload authorization The application operation, exact target resource ID and narrow Azure data-plane role are known.
- Recovery plan Application state is externally recoverable or an approved VM/data-disk backup and isolated restore path exists.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- A generation 2 Ubuntu Server 24.04 LTS Azure virtual machine created from Azure CLI 2.88.0 with Trusted Launch, Secure Boot, vTPM, encryption at host, managed disks, automatic guest patch assessment, boot diagnostics, a system-assigned managed identity and no public IP address.
- A dedicated resource group, virtual network, subnet and network security group whose inbound policy is deny-by-default, whose administration path is Azure Bastion or another approved private path, and whose application rules use service tags or narrow source ranges instead of Internet-wide management access.
- An authorization and operations model that separates Azure resource control from guest operating-system access, assigns the managed identity only the smallest data-plane role at the smallest scope, verifies IMDS behavior without exposing tokens, captures NSG and virtual-network evidence, patches through Azure Update Manager, and provides stop and rollback decisions.
- The VM has no public IP, reports Trusted Launch with Secure Boot and vTPM enabled, reports encryption at host, uses managed disks, accepts administrative access only through the documented path and exposes only the approved application port.
- The system-assigned managed identity exists, has no owner credential to rotate, can perform one required Azure operation through an exact scoped assignment, and is denied unrelated control-plane or data-plane operations.
- Operators can prove NSG association and effective rules, guest identity, boot diagnostics, patch assessment, monitoring, backup or rebuild strategy, application health and a clean negative test from an unauthorized network.
Architecture
How the parts fit together
A dedicated resource group contains a virtual network and subnet, an NSG associated explicitly with the subnet or NIC, and a generation 2 Linux VM with no public IP. Azure Virtual Network supplies private addressing; the NSG filters five-tuple flows but is not a host firewall, identity boundary or inspection device. Trusted Launch adds Secure Boot and vTPM to protect the boot chain, while encryption at host encrypts temporary disks and disk caches where supported; platform-managed or customer-managed disk encryption remains a separate decision. A system-assigned managed identity obtains short-lived tokens from the Instance Metadata Service and receives only the narrow role required by the workload. Administrators reach the host using Azure Bastion, a VPN/ExpressRoute path or a controlled jump route; they do not expose SSH to the Internet. Update Manager assesses and orchestrates patching, Azure Monitor collects platform and selected guest signals, and backup or image-based rebuild is tested independently.
- Confirm tenant, subscription, Region, quotas, approved Ubuntu image, IP plan, data classification, application port, administration path, availability, backup and deletion requirements.
- Create the resource group, VNet, subnet and NSG as code; preview the deployment with ARM/Bicep what-if and inspect all deletes, replacements and RBAC changes.
- Create the VM without a public IP and with Trusted Launch, Secure Boot, vTPM, encryption at host, managed identity, patch settings and diagnostics.
- Associate and verify the NSG, permit only the approved application source and private administration source, and use an explicit host firewall as an additional boundary when required.
- Assign one data-plane role to the managed identity at the smallest resource scope, then test an allowed operation and a denied unrelated operation from the VM.
- Verify effective networking, metadata identity, guest state, boot security, encryption, patch assessment, monitoring and recovery before application onboarding.
- Operate through alerts, Update Manager maintenance windows, VNet Flow Logs where justified, periodic role review, image and extension review, backup/rebuild drills and cost ownership.
Assumptions
- Azure CLI 2.88.0, released 2026-07-07, is the reference version. Commands use documented fields and should be revalidated after CLI or API upgrades.
- Ubuntu Server 24.04 LTS is supported for the selected VM size, Trusted Launch and Region. Image URNs are resolved and pinned in deployment evidence rather than copied from an untrusted marketplace publisher.
- The operator authenticates interactively or through workload federation with a short-lived Azure session. Subscription, tenant and role are confirmed before any resource creation.
- A private administration path exists or is created as a separate reviewed change. This guide does not attach a public IP or open TCP/22 to the Internet.
- The selected VM size and Region support Trusted Launch and encryption at host. Encryption at host is preferred for new compatible deployments because Azure Disk Encryption is scheduled for retirement on 2028-09-15.
- NSG rules are necessary but not sufficient. Host firewall, application authentication, TLS, private endpoints, route tables, Azure Firewall or another inspection control may be required by the threat model.
- A system-assigned identity is suitable when its lifecycle should follow one VM. User-assigned identities are preferable when identity lifecycle, preauthorization or reuse must be independent.
- Role assignment propagation is eventually consistent. A temporary authorization failure is measured and retried with bounds; it is not solved by granting Contributor or Owner.
- NSG flow logs are not selected for new deployments because creation ended after 2025-06-30 and retirement applies. VNet Flow Logs are used when flow evidence is required.
- No application secret is placed in cloud-init, CLI arguments, tags, custom data, extension settings or the repository. Workload secrets live in a managed secret service with identity-based access.
Key concepts
- NSG effective rules
- The combined ordered rules from every NSG associated with the NIC and subnet, including default rules. A packet must satisfy applicable associations; inspecting one rule list can miss the effective denial or exposure.
- Service tag
- A Microsoft-maintained label representing Azure service address prefixes. It simplifies policy maintenance but does not identify an individual tenant or workload and must match the intended trust boundary.
- Trusted Launch
- Azure protection for generation 2 VMs combining Secure Boot and virtual TPM, with related integrity monitoring. It protects boot integrity but does not replace patching, least privilege or application hardening.
- Encryption at host
- Host-level encryption for temporary disks and caches plus end-to-end encryption of data flowing to managed disks on supported sizes. It is distinct from guest ADE and disk encryption-set key ownership.
- Managed identity
- An Azure-managed service principal identity available to a resource. The VM requests short-lived tokens from IMDS and needs Azure RBAC assignments; there is no application password to store.
- Azure RBAC scope
- The management group, subscription, resource group or resource at which a role assignment applies. Lower, resource-specific scope usually limits blast radius better than subscription scope.
- IMDS
- The link-local Azure Instance Metadata Service reachable from the VM. Token responses are credentials and must never be printed, logged or copied into tickets.
- Control plane and data plane
- Azure resource management actions and service-specific data actions are separately authorized. Contributor may manage a resource without granting its data, and data roles should not imply resource administration.
Before you copy
Values used in this guide
{{subscriptionId}}Approved Azure subscription identifier.
Example: 00000000-0000-0000-0000-000000000000{{resourceGroup}}Dedicated lifecycle and policy boundary for the VM.
Example: rg-ops-vm-prod-weu{{location}}Approved Azure Region.
Example: westeurope{{vnetName}}Virtual network name.
Example: vnet-ops-prod-weu{{subnetName}}Application subnet name.
Example: snet-admin-tools{{vnetCidr}}Non-overlapping approved VNet prefix.
Example: 10.42.0.0/16{{subnetCidr}}Non-overlapping subnet prefix.
Example: 10.42.10.0/24{{nsgName}}NSG associated with the application subnet.
Example: nsg-admin-tools{{vmName}}Linux virtual machine name.
Example: vm-ops-01{{vmSize}}Trusted Launch and encryption-at-host compatible size.
Example: Standard_D2s_v5{{adminUsername}}Non-root guest administrative account.
Example: azureops{{sshPublicKeyPath}}Local path to the reviewed public key only.
Example: ~/.ssh/azureops_ed25519.pub{{applicationPort}}Single approved application listener.
Example: 443{{applicationSourceCidr}}Narrow trusted source range for the application.
Example: 198.51.100.0/24{{targetResourceId}}Exact Azure resource scope used by the workload.
Example: /subscriptions/<redacted>/resourceGroups/rg-data/providers/Microsoft.Storage/storageAccounts/stopsprod{{managedIdentityRole}}Narrow data-plane built-in or custom role.
Example: Storage Blob Data ReaderSecurity and production boundaries
- Never open SSH from `0.0.0.0/0` or `Internet`. Use Bastion, VPN, ExpressRoute, private access or a narrowly controlled temporary path with approval, logging and automatic expiry.
- A service tag is not a workload identity. Use application authentication and private endpoints where applicable, and verify whether the tag represents shared Microsoft or customer traffic.
- Do not print an IMDS access token. Decode only non-sensitive claims in a controlled tool when troubleshooting and revoke or remove role assignment after suspected exposure.
- System-assigned identity deletion follows VM deletion. Record its principal ID before retirement, remove assignments, and use a user-assigned identity if identity continuity must survive rebuild.
- Trusted Launch validates boot components, not the application. Continue kernel, package, image, SSH, sudo, filesystem and service hardening.
- Encryption at host is not a backup and does not give customer control over platform-managed keys. Use a disk encryption set and customer-managed keys only when ownership requirements justify the added availability dependency.
- Custom data and cloud-init can be retrieved by privileged users and platform operations. Keep secrets out, redact logs, and prefer managed identity with Key Vault data-plane permissions.
- Use PIM and time-bound eligible administration. Separate VM Contributor, network control, role-assignment administration and guest login permissions.
- Enable diagnostic settings and VNet Flow Logs only with retention, privacy, access and cost ownership. Network telemetry can contain sensitive endpoints and communication patterns.
- Before deletion, remove role assignments and verify backup/rebuild evidence. Resource group deletion is a broad destructive action and is never a routine rollback command.
Stop before continuing if
- Stop if the active tenant, subscription or Region does not match the approved change.
- Stop if the only administration design is a public IP with Internet-wide SSH.
- Stop if selected size, image or Region does not support Trusted Launch or encryption at host.
- Stop if the VNet or subnet overlaps connected networks, VPN routes, on-premises prefixes or another peered network.
- Stop if the NSG change deletes or broadens an unrelated rule, or if effective rules cannot be explained.
- Stop if managed identity requires subscription-wide Contributor, Owner or User Access Administrator for a data-plane task.
- Stop if a secret appears in custom data, CLI history, template parameters, tags, diagnostics or the repository.
- Stop if no recovery path exists for the VM data or application state.
- Stop on failed Secure Boot, vTPM, boot diagnostics, patch, application or unauthorized-source tests.
- Stop before resource-group deletion until retained dependencies and role assignments are inventoried and approved.
command
Confirm CLI, tenant, subscription, Region and providers
Authenticate with a short-lived session, select the approved subscription and inspect provider registration and compute quota before creating anything.
Why this step matters
Azure operations are scoped by the active tenant and subscription, while VM availability and quota are regional. A valid login can still point to a personal sandbox or the wrong production subscription. Capturing the context, current Azure CLI 2.88.0 reference and quota before deployment prevents accidental creation and unexplained SKU failures.
What to understand
Compare tenant and subscription identifiers with the approved change, not only their display names. Confirm the account is not a personal identity with permanent broad Owner access.
Check Microsoft.Compute, Microsoft.Network and Microsoft.ManagedIdentity provider registration, confirm the Microsoft.Compute/EncryptionAtHost feature state is Registered, and review policy denials plus availability-zone requirements before the change window.
System changes
- No Azure resources are modified; account context and quotas are read.
Syntax explained
az account show- Returns the active tenant, subscription and authenticated principal context used by subsequent CLI calls.
Values stay on this page and are never sent or saved.
az version && az account show --output jsonc && az provider show --namespace Microsoft.Compute --query registrationState --output tsv && az feature show --namespace Microsoft.Compute --name EncryptionAtHost --query properties.state --output tsv && az vm list-usage --location {{location}} --output tableazure-cli 2.88.0 TenantId: <redacted-tenant-id> Subscription: Production Platform SubscriptionId: <redacted-subscription-id> Microsoft.Compute: Registered EncryptionAtHost: Registered Name CurrentValue Limit Total Regional vCPUs 16 100
Checkpoint: Verify this layer before continuing
Continue whenAzure CLI 2.88.0 is running and tenant, subscription, Region, provider state, EncryptionAtHost registration and quota match the approved plan.
Stop whenStop on any context mismatch, unregistered required provider or EncryptionAtHost feature, insufficient quota or unapproved Region.
If this step fails
The CLI says Please run az login or shows the wrong tenant.
Likely causeThe token expired, the wrong directory was selected or cached CLI context changed.
az account list --output tableaz account show --output jsonc
ResolutionReauthenticate through the approved Entra flow, select the exact subscription and regenerate all preview evidence.
Security notes
- Never paste refresh tokens, device codes or service-principal secrets into tickets or shell scripts.
Alternatives
- Use OIDC workload federation in CI and a reviewed deployment role instead of interactive access.
Stop conditions
- Stop on any context mismatch, unregistered required provider or EncryptionAtHost feature, insufficient quota or unapproved Region.
command
Create the dedicated resource group with ownership tags
Create a lifecycle boundary in the approved Region. Apply non-sensitive owner, environment, service and cost tags so policy and incident responders can identify responsibility.
Why this step matters
A dedicated resource group provides an explicit lifecycle, RBAC, policy and cost boundary, but deletion remains broad and potentially destructive. Tags make ownership machine-readable without leaking customer data. The group location stores deployment metadata; individual resources still need an approved supported Region.
What to understand
Keep shared hubs, DNS, Bastion and central monitoring in separately owned groups if their lifecycle differs. Do not place them in the VM group merely for convenience.
Apply delete locks only after verifying the operational process for planned replacement. Locks prevent accidental control-plane deletion but do not replace backup or guest protection.
System changes
- Creates an empty Azure resource group and metadata tags.
Syntax explained
--tags- Adds non-sensitive key-value metadata used for policy, inventory, cost and ownership.
Values stay on this page and are never sent or saved.
az group create --name {{resourceGroup}} --location {{location}} --tags environment=production service=admin-tools owner=platform-recovery{
"location": "westeurope",
"name": "rg-ops-vm-prod-weu",
"properties": {"provisioningState": "Succeeded"},
"tags": {
"environment": "production",
"owner": "platform-recovery",
"service": "admin-tools"
}
}Checkpoint: Verify this layer before continuing
Continue whenThe group exists in the approved subscription and displays correct non-sensitive ownership tags.
Stop whenStop if the name collides with an existing group, inherited RBAC is unexpected or shared resources already occupy the group.
If this step fails
The group already exists with different tags or resources.
Likely causeThe name is reused or a previous deployment shares the lifecycle boundary.
az resource list --resource-group {{resourceGroup}} --output tableaz role assignment list --resource-group {{resourceGroup}} --output table
ResolutionInventory owners and dependencies; select a new reviewed boundary rather than adopting or deleting unknown resources.
Security notes
- Tags are broadly visible metadata. Never store email credentials, customer names, incident text or secrets in them.
Alternatives
- Use a subscription deployment with policy and management-group governance when the platform provisions many identical groups.
Stop conditions
- Stop if the name collides with an existing group, inherited RBAC is unexpected or shared resources already occupy the group.
command
Create the private network, subnet and NSG
Create non-overlapping address space, a dedicated subnet and an NSG. Do not create a public IP. Keep management and application access as separately reviewed rules.
Why this step matters
Private addressing and a separate NSG establish the network boundary before the VM exists. Azure NSGs are stateful and include defaults, but an empty custom ruleset is not an Internet exposure when no public IP or public load-balancer path exists. Address overlap must be resolved before peering, VPN or ExpressRoute because later renumbering is disruptive.
What to understand
Compare prefixes with every connected VNet, on-premises route, VPN pool, container network and planned private endpoint. Reserve capacity for Azure services that require dedicated subnets.
Decide whether the NSG belongs on the subnet, NIC or both. Multiple associations can add defense but also complicate effective-rule diagnosis; document ownership and avoid duplicate contradictory policy.
System changes
- Creates a VNet, subnet and unassociated NSG; no Internet-facing endpoint is created.
Syntax explained
--subnet-prefixes- Allocates the private address range from which VM NIC addresses will be assigned.
Values stay on this page and are never sent or saved.
az network vnet create --resource-group {{resourceGroup}} --name {{vnetName}} --location {{location}} --address-prefixes {{vnetCidr}} --subnet-name {{subnetName}} --subnet-prefixes {{subnetCidr}} && az network nsg create --resource-group {{resourceGroup}} --name {{nsgName}} --location {{location}}Virtual network provisioningState: Succeeded AddressSpace: 10.42.0.0/16 Subnet: snet-admin-tools 10.42.10.0/24 NetworkSecurityGroup: nsg-admin-tools ProvisioningState: Succeeded
Checkpoint: Verify this layer before continuing
Continue whenVNet and subnet prefixes are approved, non-overlapping, and the NSG exists with only Azure defaults.
Stop whenStop on overlap, wrong Region, unowned route dependencies or an existing broad custom rule.
If this step fails
The subnet prefix conflicts or is invalid.
Likely causeThe prefix is outside the VNet, overlaps an existing subnet or policy reserves it.
az network vnet subnet list --resource-group {{resourceGroup}} --vnet-name {{vnetName}} --output table
ResolutionChoose an approved non-overlapping prefix and update the network design before creating dependent NICs.
Security notes
- IP plans and peer topology are sensitive infrastructure metadata; share them only in approved systems.
Alternatives
- Use a centrally managed hub-and-spoke VNet and delegated application subnet when enterprise networking owns routing and inspection.
Stop conditions
- Stop on overlap, wrong Region, unowned route dependencies or an existing broad custom rule.
command
Add the narrow application rule and associate the NSG
Allow only the approved source CIDR to the one application port, then associate the NSG with the subnet. Administration remains on Bastion or another private path.
Why this step matters
A narrow rule makes the intended exposure explicit and leaves the default inbound deny to reject other unsolicited traffic. Associating the NSG is essential: a correctly authored but unassociated NSG protects nothing. SSH is intentionally absent because administration uses a private path.
What to understand
Rule priority is evaluated from lower number to higher number. Inspect existing custom and default rules before choosing 300, and reserve a documented priority range for platform controls.
An allow to the VM does not provide TLS or application authentication. Configure the service listener and host firewall separately, and perform an unauthorized-source negative test.
System changes
- Creates one inbound allow rule and associates the NSG with the subnet, changing packet filtering for all subnet NICs.
Syntax explained
--source-address-prefixes- Limits the allow to the approved client network instead of Internet or any source.
Values stay on this page and are never sent or saved.
az network nsg rule create --resource-group {{resourceGroup}} --nsg-name {{nsgName}} --name AllowApprovedApplication --priority 300 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes {{applicationSourceCidr}} --source-port-ranges '*' --destination-address-prefixes '*' --destination-port-ranges {{applicationPort}} && az network vnet subnet update --resource-group {{resourceGroup}} --vnet-name {{vnetName}} --name {{subnetName}} --network-security-group {{nsgName}}Rule: AllowApprovedApplication Priority: 300 Direction: Inbound Access: Allow Source: 198.51.100.0/24 DestinationPort: 443 Subnet NSG: nsg-admin-tools
Checkpoint: Verify this layer before continuing
Continue whenThe subnet references the expected NSG and only the approved source can reach the selected port; SSH remains private.
Stop whenStop if the source is Internet/Any, a higher-priority broad rule exists, or unrelated subnet workloads would be disrupted.
If this step fails
Traffic remains allowed from an unauthorized source.
Likely causeAnother higher-priority NSG, load-balancer, public IP or guest firewall policy creates a different effective path.
az network nsg rule list --resource-group {{resourceGroup}} --nsg-name {{nsgName}} --output table
ResolutionInspect effective rules and all ingress paths, remove the broad allow, test again and review logs for prior exposure.
Security notes
- Do not use service tags as tenant identity and do not log sensitive source addresses beyond approved retention.
Alternatives
- Place a private load balancer, Application Gateway or Azure Firewall in front when centralized TLS, WAF or inspection is required.
Stop conditions
- Stop if the source is Internet/Any, a higher-priority broad rule exists, or unrelated subnet workloads would be disrupted.
command
Create the hardened VM without a public IP
Create the Ubuntu 24.04 LTS VM with Trusted Launch, Secure Boot, vTPM, encryption at host, system-assigned identity, SSH public key and the prepared subnet. Verify current CLI help if a flag changes.
Why this step matters
This command materializes the security decisions in one VM creation path. Trusted Launch depends on a generation 2 image and compatible size. Encryption at host protects eligible cache and temporary storage while managed disks remain encrypted. The empty public-IP setting prevents a direct Internet management endpoint, and system-assigned identity avoids application credentials.
What to understand
Resolve the image alias to a concrete publisher, offer, SKU and version in deployment evidence. Image aliases can advance; controlled production deployments should pin and regularly refresh a trusted image.
The `--nsg ''` setting avoids CLI creating a new NIC NSG because the subnet NSG is already intentional. Verify the resulting NIC and effective rules rather than assuming empty means unprotected.
AutomaticByPlatform patching changes guest state during managed windows. Confirm orchestration, reboot, health and maintenance requirements with Azure Update Manager.
System changes
- Creates a running VM, NIC, managed OS disk, system-assigned identity and supporting diagnostic artifacts without a public IP.
Syntax explained
--security-type TrustedLaunch- Requests a generation 2 Trusted Launch security profile; Secure Boot and vTPM are explicitly enabled.
Values stay on this page and are never sent or saved.
az vm create --resource-group {{resourceGroup}} --name {{vmName}} --location {{location}} --image Ubuntu2404 --size {{vmSize}} --admin-username {{adminUsername}} --ssh-key-values {{sshPublicKeyPath}} --vnet-name {{vnetName}} --subnet {{subnetName}} --nsg '' --public-ip-address '' --security-type TrustedLaunch --enable-secure-boot true --enable-vtpm true --encryption-at-host true --assign-identity --patch-mode AutomaticByPlatform --enable-agent true{
"fqdns": "",
"id": "/subscriptions/<redacted>/resourceGroups/rg-ops-vm-prod-weu/providers/Microsoft.Compute/virtualMachines/vm-ops-01",
"location": "westeurope",
"powerState": "VM running",
"privateIpAddress": "10.42.10.4",
"publicIpAddress": "",
"resourceGroup": "rg-ops-vm-prod-weu"
}Checkpoint: Verify this layer before continuing
Continue whenThe VM runs on the private subnet, has no public IP, and reports Trusted Launch, Secure Boot, vTPM, encryption at host and a principal ID.
Stop whenStop if any requested security control is false, a public IP appears, the image publisher is unexpected or deployment creates a broad NIC NSG.
If this step fails
InvalidParameter or BadRequest is returned for security settings.
Likely causeThe image, generation, size, Region or disk configuration does not support the requested security profile.
az vm list-skus --location {{location}} --size {{vmSize}} --all --output tableaz vm image show --urn Canonical:ubuntu-24_04-lts:server:latest --output jsonc
ResolutionSelect a documented supported Gen2 image and compatible size; do not drop Trusted Launch or encryption without a reviewed exception.
Security notes
- Use only a public key. Never place a private key, password, token or application secret in CLI arguments or custom data.
Alternatives
- Deploy from a hardened image gallery version after image scanning and policy validation when organizational baselines exceed marketplace defaults.
Stop conditions
- Stop if any requested security control is false, a public IP appears, the image publisher is unexpected or deployment creates a broad NIC NSG.
verification
Verify VM security profile, identity, disks and network
Read the effective VM, NIC and identity state. Record the principal ID without retrieving an access token.
Why this step matters
Effective-state verification catches ignored or incompatible creation flags. The principal ID is the immutable object used for role assignment, while the VM name is not an authorization identity. Empty public IP, correct private address, managed disk and enabled boot controls are release gates.
What to understand
Inspect instance view and boot diagnostics for provisioning and extension errors. Trusted Launch settings in the resource model should be paired with guest and platform health evidence.
Record disk type, encryption set when used, delete option and data-disk ownership. VM deletion can remove attached disks depending on delete semantics, so recovery must not rely on an unverified default.
System changes
- No state changes; reads the VM resource model.
Syntax explained
--show-details- Adds power and IP details to the VM representation, useful for confirming absence of a public address.
Values stay on this page and are never sent or saved.
az vm show --resource-group {{resourceGroup}} --name {{vmName}} --show-details --query '{power:powerState,publicIps:publicIps,privateIps:privateIps,security:securityProfile,identity:identity,storage:storageProfile}' --output jsonc{
"identity": {"principalId":"<redacted-principal-id>","type":"SystemAssigned"},
"power": "VM running",
"privateIps": "10.42.10.4",
"publicIps": "",
"security": {
"encryptionAtHost": true,
"securityType": "TrustedLaunch",
"uefiSettings": {"secureBootEnabled":true,"vTpmEnabled":true}
}
}Checkpoint: Verify this layer before continuing
Continue whenAll security booleans are true, identity is SystemAssigned, public IP is empty, private IP is in the approved subnet and disk behavior is documented.
Stop whenStop on a false security control, absent identity, unexpected public IP, unmanaged disk or failed provisioning state.
If this step fails
securityProfile is absent or Trusted Launch flags are false.
Likely causeThe VM was created from an incompatible image/size or through a path that did not apply the requested profile.
az vm get-instance-view --resource-group {{resourceGroup}} --name {{vmName}} --output jsonc
ResolutionDo not onboard the application. Recreate from reviewed IaC with a supported image and size rather than patching an unexplained baseline.
Security notes
- Principal IDs and resource IDs are infrastructure metadata; redact them from public documentation.
Alternatives
- Use Azure Resource Graph or Policy compliance for fleet-wide verification after the single-VM pilot passes.
Stop conditions
- Stop on a false security control, absent identity, unexpected public IP, unmanaged disk or failed provisioning state.
command
Assign one least-privilege data role to the managed identity
Read the system identity principal ID and assign the required data-plane role at the exact target resource. Avoid subscription or resource-group scope unless the workload truly needs every contained resource.
Why this step matters
Managed identity removes a stored application credential but does not provide permissions by itself. A resource-scoped data role expresses exactly what the workload may do. Explicit principal type avoids directory lookup ambiguity, while the principal ID avoids assigning a similarly named identity.
What to understand
Distinguish management-plane roles such as Reader or Contributor from service data-plane roles. For Blob access, choose a Blob Data role; Contributor does not automatically provide data reads and is broader for resource management.
Role assignment can take time to propagate. Use bounded retry and acquire a fresh token rather than escalating privilege. Record the assignment ID and owner for periodic review and deletion.
System changes
- Creates one Azure RBAC assignment connecting the VM identity to the target resource.
Syntax explained
--scope {{targetResourceId}}- Limits the role assignment to one approved resource instead of inheriting across a resource group or subscription.
Values stay on this page and are never sent or saved.
principalId=$(az vm identity show --resource-group {{resourceGroup}} --name {{vmName}} --query principalId --output tsv) && az role assignment create --assignee-object-id "$principalId" --assignee-principal-type ServicePrincipal --role '{{managedIdentityRole}}' --scope '{{targetResourceId}}'{
"principalType": "ServicePrincipal",
"roleDefinitionName": "Storage Blob Data Reader",
"scope": "/subscriptions/<redacted>/resourceGroups/rg-data/providers/Microsoft.Storage/storageAccounts/stopsprod"
}Checkpoint: Verify this layer before continuing
Continue whenExactly one expected assignment exists at the target resource; inherited and unrelated assignments are absent.
Stop whenStop if the requested task requires Owner, Contributor or User Access Administrator, or if the identity already has unexpected inherited access.
If this step fails
RoleAssignmentExists or AuthorizationFailed is returned.
Likely causeThe exact assignment already exists, the operator lacks role-assignment rights or policy denies the scope.
az role assignment list --assignee-object-id "$principalId" --all --include-inherited --output table
ResolutionReuse the exact existing assignment when correct; otherwise have the authorized RBAC owner create only the narrow reviewed assignment.
Security notes
- Role assignment administration is privileged. Use PIM, approval and audit, and never grant the VM permission to assign its own roles.
Alternatives
- Use a custom role when built-in data roles include actions the workload demonstrably does not need, with an owner and regression tests.
Stop conditions
- Stop if the requested task requires Owner, Contributor or User Access Administrator, or if the identity already has unexpected inherited access.
verification
Test managed identity allowed and denied operations safely
Connect through the private administration path. Request a token only inside the VM process, pass it directly to the approved client and avoid printing it. Test one allowed read and one unrelated denied action.
Why this step matters
An assignment is only policy intent. An in-guest allowed operation proves IMDS, token audience, identity, propagation and service authorization. A negative test proves that scope is narrow. The token is a bearer credential and is intentionally not displayed; only its expiry or non-sensitive account context is shown.
What to understand
Use an approved harmless list or metadata read as the positive operation. Never validate a role by changing or deleting production data.
Select a known unrelated resource with permission to perform a safe denied read test. A 404 can hide authorization behavior, so record the service-specific denial carefully.
System changes
- No target data changes; Azure CLI caches a short-lived managed identity session in the guest process context.
Syntax explained
az login --identity- Authenticates the guest Azure CLI using IMDS and the VM's managed identity without an application secret.
az login --identity >/dev/null && az account get-access-token --resource https://storage.azure.com/ --query expiresOn --output tsv && az storage container list --account-name <approved-account> --auth-mode login --output table2026-07-28 15:42:10.000000 Name Public Access Last Modified --------- --------------- ------------------------- backups Off 2026-07-27T18:03:19+00:00 Negative test against unrelated account: AuthorizationPermissionMismatch
Checkpoint: Verify this layer before continuing
Continue whenThe approved operation succeeds, an unrelated resource is denied, no token value is logged and the role assignment is documented.
Stop whenStop if the identity can access broader data, requires a secret, or the token appears in logs, command output or support evidence.
If this step fails
The allowed operation still fails after role assignment.
Likely causePropagation is incomplete, the token is stale, the role controls a different data plane or the resource firewall/private endpoint blocks traffic.
az role assignment list --assignee-object-id <principal-id> --all --include-inherited --output table
ResolutionWait with bounded retry, clear the process session, obtain a fresh token and diagnose network versus authorization without broadening the role.
Security notes
- Do not curl and print the IMDS token response. Treat shell tracing, process arguments and debug logs as potential credential exposure.
Alternatives
- Use an Azure SDK DefaultAzureCredential path in the application and test the same allowed/denied operations in integration tests.
Stop conditions
- Stop if the identity can access broader data, requires a secret, or the token appears in logs, command output or support evidence.
verification
Validate effective NSG, routes and private administration
Inspect the VM NIC's effective NSG and route table, connect through the approved private path, test the application from an allowed and denied source and verify that no public IP resource is attached.
Why this step matters
Effective rules and routes represent what the NIC actually experiences after subnet and NIC associations. The default Internet route does not create inbound exposure without a public endpoint, but it may permit outbound traffic. Positive and negative network tests validate both intended reachability and absence of unintended reachability.
What to understand
Use Network Watcher connection troubleshoot when available to test a precise five-tuple without changing rules. Treat results as a path diagnosis, then validate the actual application and TLS behavior.
Review outbound requirements separately. NSG defaults and platform behavior can permit outbound Internet access; use firewall, NAT, route, service endpoint or private endpoint controls according to the egress threat model.
System changes
- No state changes; reads effective network policy and routes.
Syntax explained
list-effective-nsg- Combines subnet and NIC NSGs into the effective rule set applied to the interface.
Values stay on this page and are never sent or saved.
nicId=$(az vm show --resource-group {{resourceGroup}} --name {{vmName}} --query 'networkProfile.networkInterfaces[0].id' --output tsv) && nicName=${nicId##*/} && az network nic list-effective-nsg --resource-group {{resourceGroup}} --name "$nicName" --output jsonc && az network nic show-effective-route-table --resource-group {{resourceGroup}} --name "$nicName" --output tableEffective security rule: AllowApprovedApplication Inbound 300 TCP 198.51.100.0/24 * 443 Allow DenyAllInBound Inbound 65500 * * * * Deny Effective route: 10.42.0.0/16 VnetLocal 0.0.0.0/0 Internet NIC public IP configuration: none
Checkpoint: Verify this layer before continuing
Continue whenOnly approved sources reach the application, unauthorized sources and public SSH fail, private administration works and no public IP is attached.
Stop whenStop if any unexplained broad allow, route, public endpoint or unauthorized successful connection exists.
If this step fails
The effective rules command returns an empty or incomplete result.
Likely causeNIC provisioning is incomplete, permissions are insufficient or the queried NIC name/resource group is wrong.
az vm show --resource-group {{resourceGroup}} --name {{vmName}} --query networkProfile --output jsonc
ResolutionResolve the exact NIC ID, wait for provisioning and rerun with read permission; do not infer policy from the NSG object alone.
Security notes
- Flow logs and connection tests expose network metadata. Limit retention, access and ticket excerpts.
Alternatives
- Use Azure Firewall or a network virtual appliance for centralized egress policy and inspection beyond five-tuple NSG filtering.
Stop conditions
- Stop if any unexplained broad allow, route, public endpoint or unauthorized successful connection exists.
verification
Assess patches, diagnostics, monitoring and recovery
Inspect instance view and patch settings, retrieve only sanitized boot diagnostics, confirm Update Manager assessment and monitoring ownership, then perform a rebuild or backup restore drill.
Why this step matters
A secure launch configuration degrades without patch assessment, agent health, diagnostics, alerts and recovery evidence. Update Manager reports and schedules patching but application owners still own reboot tolerance, maintenance windows and post-patch validation. A VM backup is useful only when the application data and identity bindings recover correctly.
What to understand
Define alerts for VM availability, CPU/memory/disk pressure, boot integrity, extension failure, patch noncompliance, application health and unexpected NSG/RBAC changes. Every alert needs an owner and runbook.
Test either an immutable rebuild from pinned image and configuration or an approved backup restore into isolation. Reassign the exact managed identity permissions intentionally and confirm a system-assigned principal change does not leave orphaned access.
System changes
- Read checks change nothing; the operational program schedules assessments, maintenance, diagnostics and recovery drills.
Syntax explained
get-instance-view- Returns runtime provisioning, power, agent and extension status rather than only desired resource configuration.
Values stay on this page and are never sent or saved.
az vm get-instance-view --resource-group {{resourceGroup}} --name {{vmName}} --query '{statuses:instanceView.statuses,patch:osProfile.linuxConfiguration.patchSettings,agent:instanceView.vmAgent}' --output jsoncProvisioningState/succeeded PowerState/running PatchMode: AutomaticByPlatform AssessmentMode: AutomaticByPlatform VM Agent status: Ready Boot diagnostics: healthy Critical alerts: 0 Latest rebuild/restore drill: PASS Measured RTO: 00:23:18
Checkpoint: Verify this layer before continuing
Continue whenAgent and provisioning are healthy, patch assessment is current, alerts are owned, diagnostics are privacy-reviewed and rebuild/restore passes within RTO.
Stop whenStop production onboarding on failed agent, critical patch, boot, application, monitoring or recovery evidence.
If this step fails
Boot diagnostics show cloud-init or SSH provisioning errors.
Likely causeImage initialization, disk, network, package mirror, key, extension or custom-data configuration failed.
az vm boot-diagnostics get-boot-log --resource-group {{resourceGroup}} --name {{vmName}}
ResolutionPreserve sanitized evidence, repair the immutable image or provisioning source and recreate; avoid manual snowflake fixes that are absent from IaC.
Security notes
- Boot logs and guest diagnostics can contain usernames, hostnames, IPs and accidental secrets; redact before sharing.
Alternatives
- Use Azure Compute Gallery images and VMSS health-based rolling updates for replaceable fleet operation.
Stop conditions
- Stop production onboarding on failed agent, critical patch, boot, application, monitoring or recovery evidence.
verification
Record release evidence and schedule recurring review
Export sanitized resource IDs, security settings, effective rules, role assignments, policy compliance, patch state, alerts and recovery result. Schedule 90-day access review and periodic image refresh.
Why this step matters
Release evidence establishes a baseline against which policy drift and incidents can be assessed. Azure images, extensions, CLI behavior, role assignments, service retirement and workload needs change, so a secure one-time deployment is not a permanent state. A scheduled review ensures NSG rules, identities and patch policy remain necessary.
What to understand
Store only sanitized summaries and immutable deployment references. Keep raw diagnostic logs in their governed logging system rather than duplicating them into tickets.
Review inherited RBAC, PIM eligibility, system identity scope, image support, VM size, public IP inventory, NSG rules, route changes, Update Manager compliance, VNet Flow Logs and backup/rebuild evidence.
System changes
- No cloud state changes; creates governance evidence and recurring review tasks.
Syntax explained
--include-inherited- Includes assignments inherited from broader scopes so a resource-level review does not miss effective privilege.
Values stay on this page and are never sent or saved.
az vm show --resource-group {{resourceGroup}} --name {{vmName}} --query '{name:name,location:location,securityProfile:securityProfile,identityType:identity.type,provisioningState:provisioningState}' --output jsonc && az role assignment list --assignee-object-id <principal-id> --all --include-inherited --output tableRelease checks Trusted Launch: PASS Secure Boot: PASS vTPM: PASS Encryption at host: PASS Public IP absent: PASS NSG positive/negative tests: PASS Managed identity least privilege: PASS Patch assessment: PASS Recovery drill: PASS Next access review: 2026-10-26
Checkpoint: Verify this layer before continuing
Continue whenAll release gates pass, exceptions have owners and expiry, and 90-day access plus 180-day architecture reviews are scheduled.
Stop whenStop release when any control is unverified, an exception has no owner/expiry or recovery has not been exercised.
If this step fails
The role list contains unexpected inherited Contributor or Owner access.
Likely causeA subscription, management-group or resource-group assignment grants more privilege than the resource review expected.
az role assignment list --assignee-object-id <principal-id> --all --include-inherited --output jsonc
ResolutionEscalate to the RBAC owner, remove or narrow the assignment through change control and rerun positive/negative identity tests.
Security notes
- Do not publish tenant IDs, subscription IDs, principal IDs, private IPs or role topology in public evidence.
Alternatives
- Automate the baseline with Azure Policy, Resource Graph and CI assertions after manual acceptance proves the expected state.
Stop conditions
- Stop release when any control is unverified, an exception has no owner/expiry or recovery has not been exercised.
Finish line
Verification checklist
az vm show --resource-group {{resourceGroup}} --name {{vmName}} --show-details --query '{publicIps:publicIps,security:securityProfile,identity:identity.type}' --output jsoncPublic IP is empty, Trusted Launch, Secure Boot, vTPM and encryption at host are enabled, and identity type is SystemAssigned.nicId=$(az vm show -g {{resourceGroup}} -n {{vmName}} --query 'networkProfile.networkInterfaces[0].id' -o tsv); az network nic list-effective-nsg -g {{resourceGroup}} -n "${nicId##*/}" -o jsoncThe approved application source/port is allowed, default deny remains effective, private administration works and an unauthorized source is denied.az role assignment list --assignee-object-id <principal-id> --all --include-inherited --output tableThe VM identity has only the approved data-plane role at the exact resource and passes both allowed and denied operation tests.az vm get-instance-view --resource-group {{resourceGroup}} --name {{vmName}} --output jsoncProvisioning and VM agent are healthy, patch assessment is current, boot diagnostics contain no unresolved error and application checks pass.az resource list --resource-group {{resourceGroup}} --output tableResource ownership and dependencies are documented and the latest isolated rebuild or restore passed within RTO.Recovery guidance
Common problems and safe checks
Azure CLI creates resources in an unexpected subscription.
Likely causeThe active account context differs from the approved subscription or automation omitted explicit subscription scope.
az account show --output jsoncaz account list --output table
ResolutionSet and verify the approved subscription, regenerate what-if evidence and do not delete unexpected resources until ownership is confirmed.
The VM size is unavailable or quota is exceeded.
Likely causeRegional SKU availability, family quota, zone capacity or policy blocks the selected size.
az vm list-skus --location {{location}} --size {{vmSize}} --all --output tableaz vm list-usage --location {{location}} --output table
ResolutionSelect an approved compatible size or request quota; do not silently move Region or disable security features.
Trusted Launch or encryption-at-host creation fails.
Likely causeThe image generation, VM size, Region, disk configuration or feature registration is incompatible.
az vm show --resource-group {{resourceGroup}} --name {{vmName}} --output jsonc
ResolutionVerify current compatibility tables and choose a supported Gen2 image/size. Do not downgrade to an unapproved standard-security VM.
SSH cannot connect through the private path.
Likely causeBastion/VPN route, NSG effective rule, guest firewall, SSH service, username or key is incorrect.
az network nic list-effective-nsg --resource-group {{resourceGroup}} --name {{vmName}}VMNic --output jsoncaz vm boot-diagnostics get-boot-log --resource-group {{resourceGroup}} --name {{vmName}}
ResolutionTrace the private path layer by layer and use boot diagnostics or approved console access; do not add a public IP as the first response.
The application port is unreachable from an approved source.
Likely causeNSG priority, subnet/NIC combination, route, load balancer, guest firewall or application binding prevents the flow.
az network nic list-effective-nsg --resource-group {{resourceGroup}} --name {{vmName}}VMNic --output jsoncaz network nic show-effective-route-table --resource-group {{resourceGroup}} --name {{vmName}}VMNic --output table
ResolutionIdentify the exact denying layer and correct the narrow rule or listener; do not add an Any/Any allow.
An unauthorized source can reach the service.
Likely causeA higher-priority NSG rule, another NSG association, service exposure, load balancer rule or guest firewall permits it.
az network nic list-effective-nsg --resource-group {{resourceGroup}} --name {{vmName}}VMNic --output jsonc
ResolutionRemove the broad path, re-run negative tests and inspect logs for prior unauthorized access.
The managed identity endpoint returns 400 or no identity.
Likely causeThe identity is not enabled, the required Metadata header is missing or the requested resource audience is invalid.
az vm identity show --resource-group {{resourceGroup}} --name {{vmName}} --output jsonc
ResolutionEnable and verify the identity, use the documented IMDS request with Metadata:true, and never log the token response.
The identity receives AuthorizationFailed after role assignment.
Likely causeRole propagation is incomplete, scope or role is wrong, token predates the assignment, or the operation belongs to a different data plane.
az role assignment list --assignee-object-id <principal-id> --scope {{targetResourceId}} --output table
ResolutionWait with a bounded retry, obtain a fresh token and correct only the narrow assignment; do not grant Owner or Contributor.
The identity can access unrelated resources.
Likely causeA role is assigned at resource-group, subscription or management-group scope, or the identity is shared too broadly.
az role assignment list --assignee-object-id <principal-id> --all --include-inherited --output table
ResolutionRemove broad assignments, create resource-scoped roles and separate identities across trust boundaries.
Update Manager reports no assessment or stale patch state.
Likely causeAssessment mode, agent/extension health, connectivity, maintenance configuration or guest package manager state is incomplete.
az vm get-instance-view --resource-group {{resourceGroup}} --name {{vmName}} --output jsonc
ResolutionRepair supported assessment and agent prerequisites, then rerun assessment before treating the host as compliant.
NSG flow log creation is unavailable.
Likely causeNSG flow logs reached creation cutoff and retirement; the design uses a deprecated telemetry path.
az network watcher flow-log list --location {{location}} --output table
ResolutionDesign VNet Flow Logs with approved storage, privacy, retention and cost controls instead of retrying obsolete NSG flow logs.
Disk encryption status is misunderstood.
Likely causePlatform-managed disk encryption, encryption at host, disk encryption sets and retired Azure Disk Encryption concepts are being conflated.
az vm show --resource-group {{resourceGroup}} --name {{vmName}} --query '{securityProfile:securityProfile,storageProfile:storageProfile}' --output jsonc
ResolutionVerify the exact security profile and disk encryption settings against the approved threat model; do not install ADE for a new deployment by habit.
Resource group deletion is blocked or would remove shared resources.
Likely causeLocks, dependencies, shared network components or unrelated assets exist in the lifecycle boundary.
az resource list --resource-group {{resourceGroup}} --output tableaz lock list --resource-group {{resourceGroup}} --output table
ResolutionInventory ownership and dependencies, remove only approved resources individually or redesign the boundary; never force broad deletion.
Recovery
Rollback
Prefer forward correction or immutable replacement over ad-hoc guest edits. Remove traffic, preserve diagnostics, revoke the managed identity assignment, restore the last reviewed NSG/IaC and rebuild or restore into isolation before deleting any resource group.
- Remove the VM from application traffic or disable its backend membership without opening alternate broad access.
- Preserve sanitized activity logs, boot diagnostics, effective NSG and routes, VM security profile, image reference, role assignments and application evidence.
- Remove the managed identity role assignment if compromise or over-privilege is suspected; record its principal and assignment IDs.
- For a reversible NSG or RBAC error, preview and apply the last reviewed IaC state, then repeat positive and negative tests.
- For guest drift or failed boot, rebuild from the last trusted image and configuration or restore approved data into an isolated replacement rather than accumulating manual fixes.
- Do not delete the resource group until shared dependencies, locks, backup recovery, system-identity assignments and retained disks are inventoried.
- After recovery, verify Trusted Launch, encryption, no public IP, effective rules, identity least privilege, patches, monitoring and application health before restoring traffic.
Evidence