Lab Setup

Follow these steps to deploy the resources used in the lab:

Open the Azure portal at https://portal.azure.com and sign in with User1.
In the portal top bar, select the Cloud Shell icon (>_). If prompted, select Bash and No storage account required.

az provider register --namespace Microsoft.Security --wait
az provider show --namespace Microsoft.Security --query registrationState -o tsv
az group create --name sc500-lab1c-rg --location centralus --output table

Confirm the provider state is Registered, and then close Cloud Shell.
In the portal search bar, find and open Deploy a custom template.
Select Build your own template in the editor, and then select Load file.
Select deploy-lab1c-vnet.json from the F:\AllFiles\Lab-1C folder on the lab VM, and then select Save.
On the Basics page, select the existing resource group sc500-lab1c-rg and confirm Location is centralus.
Select Review + create, and then select Create.
Wait until the deployment shows Succeeded before continuing.

===

Deploy and Secure Azure Key Vault

A recent security review of your organization's AI platform found that application secrets — including the API key your Azure AI Foundry integration uses to authenticate against model endpoints — are stored in plain text inside application configuration files. Anyone with access to the deployment configuration or source repository can read them. Your task is to migrate those secrets into Azure Key Vault, restrict access so only the application's managed identity can retrieve them, and ensure the vault is protected by Defender for Key Vault.

Azure Key Vault provides a centrally managed, hardware-protected store for secrets, cryptographic keys, and certificates. When combined with managed identities, applications authenticate to Key Vault without ever handling a credential — the platform handles token acquisition automatically through the Azure Instance Metadata Service (IMDS), and access is governed by Azure RBAC role assignments. Adding a network firewall creates a second enforcement layer, ensuring that even a valid identity cannot reach the vault from an unauthorized network.

In this lab, you will:

Deploy an Azure Key Vault using the Azure RBAC authorization model
Assign role-based access to the application's managed identity and a test user account
Store an API key and a cryptographic key in the vault
Confirm that a limited Reader role does not grant access to secret values
Retrieve the secret using the App Service managed identity via the managed identity token endpoint
Restrict vault network access to an authorized virtual network
Enable the Defender for Key Vault protection plan and configure audit log forwarding

This exercise should take approximately 60 minutes to complete.

Note: The deployed App Service name begins with sc500-lab1c-app- followed by an automatically generated suffix. Throughout this lab, <app-service-name> refers to that App Service.

Note: This lab uses two accounts: your User1 account (your primary lab credentials and Administrator) and User2 (used to verify that role-based access boundaries are enforced at the data plane). Use the credentials provided for both accounts.

Deploy the Key Vault

Azure Key Vault supports two permission models: Vault access policies (the legacy model) and Azure role-based access control (the recommended model). The RBAC model integrates Key Vault access governance into the same role assignment system used across all Azure resources, making it easier to audit permissions and apply the principle of least privilege consistently. You will create the vault with the RBAC model enabled and then verify and configure its deletion protection settings.

Note: Key Vault names must be globally unique across all Azure subscriptions. In the next step you will pick your own name that begins with sc500-kv- (for example, sc500-kv-yourinitials-1234). Throughout the rest of this lab, <your-kv-name> refers to whatever name you entered here — write it down or leave a Notepad window open with it, since you will reuse it in later sections.

Sign in to the Azure portal using https://portal.azure.com using your User1 credentials.
In the search bar, search for and select Key vaults.
Select + Create.

On the Basics tab, configure the following:

Setting	Value
Subscription	Your lab subscription
Resource group	sc500-lab1c-rg
Key vault name	A globally unique name starting with `sc500-kv-` (for example, `sc500-kv-yourinitials-1234`). Record it as `<your-kv-name>` for later steps.
Region	Use the region selected during Lab Setup (East US unless your lab environment directed otherwise)
Pricing tier	Standard

Select the Access configuration tab.
Under Permission model, select Azure role-based access control (RBAC).

Note: The RBAC authorization model is selected at vault creation and cannot be changed without deleting and recreating the vault. If the vault is created with the legacy access policies model, the role assignment steps in this lab will not apply.
Select Review + create, then select Create.

Wait for the deployment to complete. This typically takes less than one minute.
Select Go to resource to open the vault.
On the Key Vault Overview page, locate the Vault URI field. Copy this value and save it — it follows the format https://<your-kv-name>.vault.azure.net/. You will use it in a later section. NOTEPAD in Windows is a great tool for saving this information.
In the left menu, under Settings, select Properties.
Locate Soft-delete and confirm it shows Soft delete is enabled for this vault.

Note: Soft delete is enabled by default on all new Key Vault instances and cannot be disabled once set. It retains deleted secrets, keys, and certificates in a recoverable state for a configurable retention period (default: 90 days), protecting against accidental or malicious deletion.
Locate Purge protection and confirm it shows Disabled.
Select Enable purge protection, then select Save.

Note: Purge protection prevents permanent deletion of the vault or its objects during the soft-delete retention period, even by users with the Key Vault Contributor role. This is a one-way operation and cannot be reversed after it is enabled. In production environments, purge protection is recommended for any vault storing critical secrets or keys.

Configure access using Azure RBAC

With the vault created, you will assign four RBAC roles following the principle of least privilege. Rather than granting a broad administrator role to your User1 Administrator account, you will assign two targeted roles: Key Vault Secrets Officer (to create and manage secrets) and Key Vault Crypto Officer (to create and manage keys). You will then grant the Key Vault Secrets User role to the App Service managed identity (which will retrieve secrets at runtime), and the Key Vault Reader role to User2 (which you will use to verify that management-plane access does not grant data-plane access to secret values).

Note: When a Key Vault uses the RBAC authorization model, data-plane access is controlled entirely by role assignments — including for the account that created the vault. The subscription Owner role and the Global Administrator role do not grant any data-plane rights to Key Vault. Without an explicit assignment, your admin account cannot create, read, or delete secrets or keys.

The <app-service-name> App Service has a system-assigned managed identity that was pre-enabled before the lab started. You do not need to configure the App Service itself — you only need to grant the identity access to this vault.

In the left menu of the Key Vault, select Access control (IAM).
Select + Add, then select Add role assignment.
On the Role tab, search for and select Key Vault Secrets Officer, then select Next.

Note: The Key Vault Secrets Officer role grants create, read, update, delete, and purge permissions for secrets only — it does not include access to keys or certificates. Assigning it separately from Key Vault Crypto Officer enforces separation: an account with only Secrets Officer cannot manage keys, and vice versa.
On the Members tab, confirm Assign access to is set to User, group, or service principal.
Select + Select members, search for and select your User1 account (the account you are currently signed in with), then select Select.
Select Review + assign, then select Review + assign again to save.
Select + Add, then select Add role assignment to begin a second assignment.
On the Role tab, search for and select Key Vault Crypto Officer, then select Next.

Note: The Key Vault Crypto Officer role grants create, read, update, delete, and purge permissions for keys only. Separating key management from secrets management is a Zero Trust design principle — the person or process that manages encryption keys is not automatically the same one that can read application secrets.
On the Members tab, confirm Assign access to is set to User, group, or service principal.
Select + Select members, search for and select your User1 account (the account you are currently signed in with), then select Select.
Select Review + assign, then select Review + assign again to save.
Select + Add, then select Add role assignment to begin a third assignment.
On the Role tab, search for and select Key Vault Secrets User, then select Next.

Note: The Key Vault Secrets User role grants read access to secret contents only — just enough for an application to retrieve a secret value at runtime. It does not allow creating, updating, listing, or deleting secrets. This is the minimum permission required for an application's managed identity to read a secret.
On the Members tab, set Assign access to to Managed identity.
Select + Select members.
On the Select managed identities pane, set Managed identity to App Service, then select from the list.
Select Select, then select Review + assign, then select Review + assign again to save.
Select + Add, then select Add role assignment to begin a fourth assignment.
On the Role tab, search for and select Key Vault Reader, then select Next.

Note: The Key Vault Reader role grants read access to Key Vault metadata — vault properties, and the names of secrets and keys — but does not grant permission to view secret values or key material. It is a management-plane role only. You will verify this boundary in the next section.
On the Members tab, set Assign access to to User, group, or service principal.
Select + Select members, search for and select User2, then select Select.
Select Review + assign, then select Review + assign again to save.
On the Access control (IAM) page, select the Role assignments tab and confirm the following four assignments are listed:

Principal Role

User1 Key Vault Secrets Officer

User1 Key Vault Crypto Officer

Key Vault Secrets User

User2 Key Vault Reader

Note: In a production environment, consider making the Key Vault Secrets Officer and Key Vault Crypto Officer assignments eligible through Privileged Identity Management (PIM) rather than active. This removes standing data-plane access entirely — administrators activate the role just-in-time when they need to manage vault contents, and access automatically expires.

Principal	Role
User1	Key Vault Secrets Officer
User1	Key Vault Crypto Officer
	Key Vault Secrets User
User2	Key Vault Reader

Store secrets and keys

You will now store two objects in the vault: a secret that represents the AI application's model endpoint API key, and a cryptographic key that represents a data encryption key managed through Key Vault. These objects will be used in the access verification and managed identity retrieval steps that follow.

In the left menu of the Key Vault, select Objects then Secrets.
Select + Generate/Import.
On the Create a secret page, configure the following:

Setting Value

Upload options Manual

Name foundry-api-key

Secret value sk-foundry-demo-00000000000000000000000000000001

Enabled Yes
Select Create.

The secret appears in the Secrets list with a status of Enabled.
In the left menu, select Keys.
Select + Generate/Import.
On the Create a key page, configure the following:

Setting Value

Options Generate

Name data-encryption-key

Key type RSA

RSA key size 2048

Enabled Yes
Select Create.

The key appears in the Keys list with a status of Enabled.

Note: Key Vault stores the RSA private key material inside the vault and never exposes it directly. Applications interact with the key by calling Key Vault cryptographic operations — encrypt, decrypt, sign, verify — rather than extracting the raw key. This keeps the private key permanently protected and audited inside the vault.

Setting	Value
Upload options	Manual
Name	`foundry-api-key`
Secret value	`sk-foundry-demo-00000000000000000000000000000001`
Enabled	Yes

Setting	Value
Options	Generate
Name	`data-encryption-key`
Key type	RSA
RSA key size	2048
Enabled	Yes

Verify access control enforcement

The Key Vault Reader role grants management-plane access only — a user assigned this role can see that secrets exist and view their names, but cannot read secret values. You will sign in as User2 to confirm that the role boundary is enforced at the data plane.

Open a new InPrivate or Private browser window.
Navigate to the Azure Portal at https://portal.azure.com and sign in using the credentials provided for User2.
In the search bar, search for and select Key vaults.
Select <your-kv-name> from the list.
In the left menu open Objects, then select Secrets.

Confirm that foundry-api-key appears in the list. The Key Vault Reader role grants User2 management-plane access, so the secret name is visible.
Select foundry-api-key to open the secret, then select the current version.
On the secret version page, select Show Secret Value.

Confirm that an error message appears, such as "The operation is not allowed by RBAC. If role assignments were recently changed, please wait several minutes for role assignments to become effective." or an access denied notification.

Note: The Key Vault Reader role includes Microsoft.KeyVault/vaults/read (management plane) but does not include Microsoft.KeyVault/vaults/secrets/getSecret/action (data plane). This means User2 can enumerate secrets but cannot retrieve their values — precisely the boundary that separates the Reader role from the Secrets User role.
Close the InPrivate browser window and return to your User1 browser session.

Retrieve a secret using the managed identity

The <app-service-name> App Service managed identity has the Key Vault Secrets User role, which grants data-plane access to secret values. The app runs on Linux, so you will open an SSH session to its container and retrieve the foundry-api-key secret by using a bearer token issued to the managed identity. No user credentials are involved in this retrieval.

When managed identity is enabled on an App Service, the runtime injects two environment variables into the application's process: IDENTITY_ENDPOINT (a local token service URL) and IDENTITY_HEADER (a shared secret that prevents SSRF attacks). Code running inside the App Service uses these values to request OAuth tokens scoped to an Azure resource.

Note: Managed identity requires a Basic (B1) tier App Service or higher. The Free (F1) tier does not support managed identities. The setup template deploys this app on B1.

Confirm you are signed in to the Azure portal at https://portal.azure.com as User1. If the InPrivate window from the previous section is still active, close it first.
Open App Services, and then select .
Under Development Tools, select SSH, and then select Go.

A Web SSH tab opens and displays SSH CONNECTION ESTABLISHED. Run the remaining Bash commands in this Web SSH terminal.
Run the following commands to verify the managed identity environment variables are present:
```
printf 'IDENTITY_ENDPOINT: %s\n' "$IDENTITY_ENDPOINT"
if [ -n "$IDENTITY_HEADER" ]; then
  echo 'IDENTITY_HEADER is set: True'
else
  echo 'IDENTITY_HEADER is set: False'
fi
```
Expected output:
```
IDENTITY_ENDPOINT: http://127.0.0.1:<port>/MSI/token
IDENTITY_HEADER is set: True
```
Important: If IDENTITY_ENDPOINT is blank or IDENTITY_HEADER is set: False, exit the SSH session. Navigate to > Settings > Identity and confirm the System assigned status is On. Also confirm the App Service plan uses the Basic (B1) tier or higher.

Run the following commands to request a bearer token for Azure Key Vault and extract it with the Node.js runtime already installed in the container:

token_response=$(curl --silent --show-error --fail \
  "${IDENTITY_ENDPOINT}?resource=https%3A%2F%2Fvault.azure.net&api-version=2019-08-01" \
  -H "X-IDENTITY-HEADER: ${IDENTITY_HEADER}")

token=$(printf '%s' "$token_response" | node -e \
  'let input=""; process.stdin.on("data", c => input += c); process.stdin.on("end", () => process.stdout.write(JSON.parse(input).access_token));')

echo "Token acquired: ${token:0:20}..."

A partial token value confirms that the managed identity returned a valid token.

Note: App Services use a local token endpoint instead of the virtual-machine IMDS address (169.254.169.254). The X-IDENTITY-HEADER value prevents unauthorized processes from requesting tokens through that endpoint.

Run the following commands. Replace <your-kv-name> with the Key Vault name you recorded earlier:

kv_uri="https://<your-kv-name>.vault.azure.net"
secret_response=$(curl --silent --show-error --fail \
  "${kv_uri}/secrets/foundry-api-key?api-version=7.4" \
  -H "Authorization: Bearer ${token}")

secret_value=$(printf '%s' "$secret_response" | node -e \
  'let input=""; process.stdin.on("data", c => input += c); process.stdin.on("end", () => process.stdout.write(JSON.parse(input).value));')

echo "Secret value: ${secret_value}"

The output should display the secret value you stored earlier:

Secret value: sk-foundry-demo-00000000000000000000000000000001

Note: The bearer token identifies the <app-service-name> managed identity to Key Vault. Key Vault confirms that the identity holds the Key Vault Secrets User role before returning the value.

Run exit to close the App Service SSH session, then close Cloud Shell.

Restrict network access

Identity-based access control is the primary enforcement mechanism for Key Vault. A network firewall adds a second layer of defense by limiting which networks can reach the vault's data plane, regardless of role assignments. You will configure the Key Vault firewall to allow access only from the sc500-lab1c-vnet virtual network.

Note: The sc500-lab1c-vnet virtual network was pre-provisioned with the Microsoft.KeyVault service endpoint already enabled on its subnet. This is required before a VNet can be added to a Key Vault firewall allow list — the service endpoint configures the subnet to route Key Vault traffic directly through the Azure backbone rather than through the public internet.

Navigate to your Key Vault, <your-kv-name>.
In the left menu, under Settings, select Networking.
Under Allow access from, select Allow public access from specific virtual networks and IP addresses.
Under Virtual networks, use the dropdown to select + Add existing virtual networks.
On the Add networks pane, configure the following:

Setting Value

Subscription Your lab subscription

Virtual networks sc500-lab1c-vnet

Subnets Select the available subnet - default
Select Add.
Under Exceptions, confirm that Allow trusted Microsoft services to bypass this firewall is selected.

Note: The trusted Microsoft services exception allows Azure platform services — such as Azure Monitor, Azure Backup, and Azure Defender — to access the vault for monitoring and protection purposes, even when the firewall restricts all other traffic.
Select Apply to save the firewall configuration.

Note: After saving, the vault accepts data-plane traffic only from the sc500-lab1c-vnet subnet and from Azure services on the trusted services list. The Azure portal may display a banner warning that your current IP is not in the allow list — this is expected. If you need to access the vault from the portal after this step, you can temporarily add your lab environment's public IP to the IP addresses section of the firewall, or use an Azure resource that is VNet-integrated with sc500-lab1c-vnet.

Enable Defender for Key Vault

Microsoft Defender for Key Vault detects unusual and potentially harmful access patterns — including access from known malicious IP addresses, suspicious retrieval volumes, and anomalous geographic locations. You will enable the Defender for Key Vault protection plan on the subscription and configure the vault to forward audit logs to the pre-provisioned Log Analytics workspace.

In the Azure portal https://portal.azure.com search bar, search for and select Microsoft Defender for Cloud.
In the left menu, under Management, select Environment settings. Scroll to the bottom of the page.
Use the Expand All button to expand your subscription node and select your subscription.
On the Defender plans page, locate Key Vault in the list of resource types.
Set the Key Vault plan status to On.
Select Save.

Note: Enabling Defender for Key Vault activates threat detection across all Key Vaults in the subscription, including the vault you created in this lab. Alerts are generated for anomalies such as access from Tor exit nodes, access from atypical geographic locations, and bulk secret retrieval patterns that may indicate a credential harvesting attempt.
Navigate back to your Key Vault, <your-kv-name>.
In the left menu, under Monitoring, select Diagnostic settings.
Select + Add diagnostic setting.

Configure the following:

Setting	Value
Diagnostic setting name	`sc500-kv-diag`
Logs — Category groups	Check audit
Destination details	Check Send to Log Analytics workspace
Subscription	Your lab subscription
Log Analytics workspace	sc500-lab1c-log

Select Save.
Confirm that sc500-kv-diag now appears in the Diagnostic settings list.

Note: Diagnostic settings forward all Key Vault audit events — read, write, and delete operations on secrets, keys, and certificates — to the Log Analytics workspace. This telemetry feeds into Defender for Key Vault alert enrichment and supports security investigations and compliance reporting. Allow up to 15 minutes for the first log entries to appear in the workspace after the setting is saved.

Summary

In this lab, you secured an Azure Key Vault from end to end. You deployed the vault using the RBAC authorization model, ensuring access governance integrates with the same role assignment system used across all Azure resources. You granted the App Service managed identity the minimum required permission — Key Vault Secrets User — and confirmed that the Key Vault Reader role assigned to User2 enforces the management-plane and data-plane boundary: the user can see that a secret exists but cannot read its value. You stored a simulated AI application API key and a cryptographic key, then retrieved the secret programmatically from the App Service using a managed identity bearer token acquired from the App Service managed identity endpoint — with no stored credentials involved at any step. Finally, you applied a network firewall to restrict vault access to an authorized virtual network, enabled the Defender for Key Vault protection plan, and configured audit log forwarding to a Log Analytics workspace.

You have successfully completed this exercise.

Clean up

The lab environment is automatically reset at the end of the session. No manual resource deletion is required.

If you want to clean up before the session ends:

Navigate to the Azure portal.
Navigate to Resource groups and select sc500-lab1c-rg.
Select Delete resource group, enter the resource group name to confirm, and select Delete.
In Microsoft Defender for Cloud → Management → Environment settings, select your subscription and set the Key Vault plan to Off, then select Save.

Setting	Value
Subscription	Your lab subscription
Virtual networks	sc500-lab1c-vnet
Subnets	Select the available subnet - default