Azure DevOps, GitHub CI agents, and Fabric Notebooks run on Microsoft-managed virtual machines and may use hundreds of IP ranges per region. Because these services are not recognized as trusted services by Azure Key Vault, the firewall often has to remain publicly accessible to allow them to connect through Microsoft's shared backbone infrastructure. Why aren't these Microsoft-managed services included in the trusted services exception, and what is the recommended way to secure Key Vault access without maintaining large IP allowlists?
4 Answers
Managed identities, network security perimeters, and private endpoints are the direction to consider for a stronger design. The exact combination depends on which services support your scenario, but the goal is to avoid leaving the Key Vault broadly reachable just because a shared Microsoft service needs access.
For Azure DevOps and GitHub-based pipelines, self-hosted agents or managed DevOps pools are usually the better option. You can place the agents in a controlled network and give them private access to Key Vault instead of allowing broad public access. Fabric also supports managed private endpoints, which can help keep notebook traffic private.
The main reason is that these services execute customer-provided code. Even though Microsoft manages the underlying infrastructure, a pipeline or notebook can run arbitrary commands, so treating the entire service as trusted would create a large security boundary. Microsoft therefore doesn’t automatically grant these workloads trusted-service access to Key Vault.
If you must use Microsoft-hosted agents, a temporary firewall rule can be created at the start of the pipeline using the agent’s public IP, then removed during cleanup. It works, but it’s more fragile than private connectivity and needs to account for failed or canceled runs.
That approach also makes the firewall rules much easier to manage because you authorize the network or private endpoint rather than tracking Microsoft-hosted agent IP ranges.