3.2 Access Control and Firewall for Key Vault

Two Planes, Two Authorization Stories

Every SC-500 scenario about Key Vault access starts with this split:

Authentication for both planes is Microsoft Entra ID. Having a valid Entra token is never enough—you still need the right role or policy and an allowed network path for data-plane calls when the firewall is on.

---

Access Policies vs Azure RBAC Data Plane

Legacy access policies

An access policy is a vault-level entry that grants a specific security principal (user, group, service principal, or managed identity) a set of key, secret, and/or certificate permissions (get, list, set, delete, purge, crypto ops, and so on). Policies live on the vault resource. They do not manage who can create the vault or change its firewall—that remains Azure RBAC on the control plane.

Limits of access policies:

• Vault-wide grants; poor fit for centralized identity governance across many vaults
• Harder to audit consistently with Azure Activity Log role assignment history
• Mixing models is confusing; switching to RBAC clears policy-based data access

Azure RBAC for Key Vault data plane

RBAC assigns built-in (or custom) roles at management group, subscription, resource group, vault, or even individual key/secret/certificate scope. Microsoft recommends one vault per application per environment with roles at vault scope, not per-object assignments, except for rare sharing cases.

Exam trap: Key Vault Contributor is a control-plane role. It lets someone manage vault properties. With the access-policy model, a Contributor can often grant themselves data-plane access by editing policies. Treat Contributor as privileged. Prefer RBAC data plane so management of the resource and use of secrets stay cleanly separated.

---

Who Can Manage the Vault vs Use Secrets

Think in least privilege:

1. Manage vault (networking, diagnostics, locks, delete): control-plane RBAC such as Contributor or custom roles with Microsoft.KeyVault/vaults/* write actions.
2. Use secrets (read at runtime): data-plane Secrets User (or access-policy get/list on secrets only).
3. Rotate / write secrets: Secrets Officer—not every app identity.
4. Purge: separate Purge Operator or highly restricted Administrator path; combine with purge protection.

Scenario: DevOps engineers deploy App Service slots. Give the deployment pipeline identity Secrets Officer (or scoped set) only on the non-prod vault. Give the App Service managed identity Secrets User only. Do not put human Contributors on production vaults without PIM and justification.

---

Firewall, Service Endpoints, and Private Endpoints

Firewall modes (conceptual)

Constraints to memorize:

• Max 200 virtual network rules and 1000 IPv4 rules
• IP rules accept public IPv4 only—not RFC1918 private ranges
• Service endpoint: enable Microsoft.KeyVault on the subnet, then add the subnet to the vault network rules
• After rules apply, portal users may open the vault blade but fail to list secrets if their client IP is not allowed

Private endpoints (Private Link)

Private endpoints map the vault’s data-plane FQDN into a private IP in your VNet via Private Link DNS (privatelink.vaultcore.azure.net). Best practice for sensitive workloads:

1. Create private endpoint + private DNS zone links for all consuming VNets/hubs
2. Set public network access to Disabled
3. Confirm apps use the vault URI and resolve privately

Public DNS may still resolve the vault name to a public ingress that refuses traffic when public access is disabled—that is expected and does not expose private IP or secrets.

Service endpoints vs private endpoints: Service endpoints keep traffic on the Azure backbone to the public data-plane VIP but restrict source VNets. Private endpoints bring the service into your private address space and support full public disablement. SC-500 “most secure network isolation” answers usually prefer private endpoint + public access disabled.

---

Trusted Microsoft Services

When the firewall is on, you may allow trusted Microsoft services to bypass network rules. Important nuances:

• Bypass covers a documented list (Storage CMK, SQL TDE BYOK, Disk Encryption, Backup, Resource Manager template deployment of secure values, and many others).
• Services not on the list (classically Azure DevOps custom pipelines) do not get blanket bypass—use private endpoints, self-hosted agents on allowed VNets, or IP rules.
• Bypass does not skip authentication or authorization; the service still needs a valid identity and data-plane rights.
• With Network Security Perimeter in enforced mode, trusted bypass can be overridden—perimeter rules govern access.

---

Managed Identity Access Patterns

Preferred application pattern:

1. Enable system-assigned or user-assigned managed identity on App Service, Function, VM, AKS workload identity, Logic Apps, and so on.
2. Assign Key Vault Secrets User (and Crypto User if needed) on the vault or secret scope.
3. Application retrieves secrets via SDK/REST using Entra token for that identity—no client secret in app settings.
4. Combine with Key Vault references in App Service configuration where supported, still backed by the app’s managed identity.
5. Optionally constrain with ABAC conditions on secret names (preview capabilities for secret data actions).

Anti-pattern (exam wrong answer): Store a service principal password in App Service application settings that is also used to call Key Vault. Prefer managed identity end-to-end.

User-assigned identity shines when multiple resources share one identity lifecycle or when blue/green slots need a stable identity across restarts.

SC-500 Exam Traps (Access & Network)

• Contributor on the vault ≠ ability to read secrets under pure RBAC without a data role—but with access policies, Contributor can self-elevate.
• Key Vault Reader cannot read secret values.
• Firewall does not secure control plane; private endpoint is about data plane connectivity.
• Trusted services list is not “all of Azure.”
• Apps need Secrets User, not Key Vault Administrator.