PaaS Network Boundary Needed? Configure Network Security Perimeter

Azure PaaS services expose data-plane endpoints without placing the service itself inside your virtual network. Configuring each resource’s public network rules independently becomes difficult as the number of services grows. Azure Network Security Perimeter (NSP) creates one logical boundary around supported PaaS resources and centrally controls their public inbound and outbound traffic.

In this trip, create a dedicated Key Vault, associate it with an NSP profile, allow only your workstation’s public IPv4 address, and change the association from Transition to Enforced mode.

Administrator public IPv4
          |
          | inbound access rule
          v
Network Security Perimeter profile
          |
          v
      Azure Key Vault

NSP protects public data-plane access. Microsoft Entra authentication and Key Vault RBAC still decide what an admitted caller may do. A network allow rule does not grant access to secrets.

These network controls solve different problems:

Control	Endpoint used	Main purpose	Behavior with NSP
Network Security Perimeter	Public PaaS endpoint	Restricts which public sources can reach associated PaaS resources	NSP access rules control public traffic
Private Endpoint (Private Link)	Private IP inside your VNet	Gives workloads private VNet connectivity to the PaaS resource	Allowed without an NSP public access rule
Service Endpoint	Public PaaS endpoint, with traffic identified by its source subnet	Allows a PaaS resource firewall to trust selected subnets	Not supported for NSP-associated resources

Use a private endpoint when a workload must reach the PaaS resource through a private VNet address. Use NSP when approved callers must use the resource’s public endpoint.

When to Use a Service Endpoint

VM in an approved subnet
          |
          | identified as traffic from snet-app
          v
Key Vault public endpoint

A service endpoint allows a PaaS resource firewall to trust traffic from selected VNet subnets. The service still uses its public endpoint and does not receive a private IP address in your VNet. Configuration is normally repeated for every PaaS resource, but it does not require a private endpoint or private DNS.

Use a service endpoint when one or a few VNet subnets need controlled access to one PaaS resource and using the service’s public endpoint is acceptable. Do not use it for an NSP-associated resource; choose a private endpoint when that resource needs VNet connectivity.

When to Use Network Security Perimeter

Approved laptop public IP ----+
Key Vault                     +--> NSP profile
Storage account --------------+

NSP centrally controls public access to multiple associated PaaS resources. Inbound rules can admit approved public IP ranges or subscriptions, while supported outbound rules can restrict destination FQDNs. This makes NSP useful when an organization needs one public network boundary instead of maintaining independent public-access rules on every service.

Use NSP when approved administrators, applications, or services must access one or more PaaS resources through their public endpoints.

When to Use a Private Endpoint

VM private IP:        10.20.1.4
          |
          | private VNet path
          v
Key Vault endpoint:   10.20.2.5

A private endpoint creates a network interface with a private IP address in your VNet. Private DNS resolves the normal service hostname to that private IP for connected clients. Public access can then be disabled. This provides strong private network isolation, but it requires private-endpoint lifecycle and DNS configuration.

Use a private endpoint when workloads in a VNet, an on-premises network, or a VPN-connected network must reach the PaaS resource without using its public endpoint.

For CloudTrips, choose:

Requirement	Appropriate control
An administrator’s laptop reaches Key Vault through its approved public IP	Network Security Perimeter
A VM subnet reaches a non-NSP PaaS resource through its public endpoint	Service Endpoint
A VM reaches PaaS through a private IP inside the VNet	Private Endpoint

These resources can incur charges. Complete the cleanup at the end of the trip. NSP names and locations shown in the portal can vary slightly as the service evolves.

Create a Dedicated Key Vault

Set reusable names in Azure Cloud Shell. The generated Key Vault name is globally unique and remains below its 24-character limit:

RG_NAME="rg-cloudtrips-network-test-weu"
LOCATION="westeurope"
SUBSCRIPTION_ID=$(az account show --query id --output tsv)
NSP_VAULT="kv-ct-nsp-${SUBSCRIPTION_ID//-/}"
NSP_VAULT=${NSP_VAULT:0:24}

az keyvault create \
  --resource-group "$RG_NAME" \
  --name "$NSP_VAULT" \
  --location "$LOCATION" \
  --enable-rbac-authorization true

printf 'Key Vault: %s\n' "$NSP_VAULT"

Keep the printed vault name. The NSP association generated by the portal also uses the resource name, so concise resource names avoid association-name length problems.

Create the Perimeter and Profile

In the Azure portal, search for Network security perimeters and select Create. On Basics, configure:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: nsp-cloudtrips-test-weu
Region: West Europe
Profile name: profile-cloudtrips-paas

Select Review + create > Create. A perimeter is the top-level boundary; the profile contains resource associations and access rules. Multiple supported PaaS resources can later join the same profile.

Associate the Key Vault in Transition Mode

Open nsp-cloudtrips-test-weu, select Settings > Profiles, and open profile-cloudtrips-paas. Under Associated resources, select Add and choose the Key Vault printed earlier.

Keep the association in Transition mode initially. Transition is the safe starting state: it records how the perimeter would affect public access while the resource’s existing network controls continue to apply. Confirm the association shows:

Resource type: Microsoft.KeyVault/vaults
Access mode: Transition

You do not have to change Public network access to SecuredByPerimeter for this lab. In Transition mode, the Key Vault’s existing publicNetworkAccess setting still controls access. After you change the association to Enforced, NSP rules override that setting and control public access.

Allow One Administrator Address

Determine the public IPv4 address used by the workstation from which you will test. Use an organization-approved IP lookup or ask the network team. Do not enter the workstation’s private 10.x, 172.16-31.x, or 192.168.x address. If a VPN or NAT gateway changes the public address, the rule no longer matches. Azure Cloud Shell also uses a different egress address, so run the final test from the same workstation represented by the rule.

In profile-cloudtrips-paas, select Inbound access rules > Add:

Rule name: Allow-Admin-IPv4
Source type: IP address ranges
Allowed sources: <your-public-IPv4>/32

/32 permits exactly one IPv4 address. Do not use 0.0.0.0/0, because that would admit every public IPv4 source and defeat this lab’s boundary.

No outbound rule is required for this Key Vault test. Outbound NSP rules use fully qualified domain names and are needed only when an associated service initiates supported public outbound connections.

Enforce and Verify the Boundary

Return to Associated resources, open the Key Vault’s ellipsis menu, and select Change access mode > Enforced. Confirm the change. In Enforced mode, public traffic is denied unless it comes from within the same perimeter or matches an explicit access rule. Private-endpoint traffic remains allowed.

From the workstation whose public IP is allowed, replace the placeholder and send an unauthenticated request to the Key Vault data plane:

NSP_VAULT="<printed-key-vault-name>"

curl --include --max-time 10 \
  "https://${NSP_VAULT}.vault.azure.net/secrets?api-version=7.4"

An authentication or authorization response proves that the request passed the network boundary and reached Key Vault; it does not mean secret access was granted. The response must not report that the client address is forbidden by the network security perimeter.

For a negative test, send the same request from a machine with a different public IP. That request should be rejected by the perimeter. Do not broaden the rule merely to make a changing Cloud Shell egress address work.

Remove the Perimeter Lab

Do not delete a perimeter while leaving an application resource unintentionally secured by it. In profile-cloudtrips-paas:

1. Open Associated resources and change the Key Vault to Transition.
2. Remove the Key Vault association.
3. Delete Allow-Admin-IPv4.
4. Delete profile-cloudtrips-paas, then nsp-cloudtrips-test-weu.

Finally delete only the dedicated lab vault:

az keyvault delete \
  --resource-group "rg-cloudtrips-network-test-weu" \
  --name "$NSP_VAULT"

Keep the CloudTrips VNets, load balancer, VMs, Network Watcher, and all application resources. NSP governed a PaaS data-plane boundary; it did not replace their NSGs or Virtual Network Manager configuration.