Azure DevOps/Pipeline IP随机变更致无法使用Azure SQL Database的解决方案咨询

Let’s break down the practical, actionable fixes for when your Azure DevOps pipeline’s dynamic IPs get blocked by Azure SQL Database firewall rules. Each solution has its own use case, so pick the one that fits your team’s security and operational needs:

1. Allow Azure DevOps Managed Agent IP Ranges #

Azure publishes the IP ranges for its managed agents by region. You can add these ranges to your SQL Database firewall to ensure your pipeline always has access.

• How to implement:
  1. Use the Azure CLI to fetch the latest IP ranges for your pipeline's region:

     az network list-service-tags --location eastus --query "values[?properties.systemService=='AzureDevOps'].properties.addressPrefixes" --output tsv
     

     Replace eastus with your pipeline's actual region.
  2. Bulk-add these IP prefixes to your Azure SQL Database firewall rules via the Azure Portal, Azure CLI, or an ARM template.
• Pros: Works with out-of-the-box managed agents, no extra infrastructure to maintain initially.
• Cons: IP ranges are updated periodically (usually monthly), so you’ll need to set up a recurring process to refresh the rules to avoid future blocks.

2. Use a Self-Hosted Agent in Your VNet #

Deploying a self-hosted agent inside your Azure Virtual Network (VNet) lets you leverage VNet-level firewall rules instead of tracking public IPs.

• How to implement:
  1. Provision a VM (or container) inside the VNet connected to your Azure SQL Database (or a peered VNet).
  2. Install the Azure DevOps self-hosted agent on this VM using the setup instructions from your Azure DevOps organization.
  3. Add a VNet rule to your Azure SQL Database firewall, allowing traffic from your VNet’s address space.
• Pros: No public IP management required, traffic stays within your private network for better security, stable long-term access.
• Cons: Requires ongoing maintenance of the self-hosted agent (updates, scaling, availability checks).

3. Use Azure SQL Private Endpoint #

For the highest security posture, set up a private endpoint for your Azure SQL Database. This makes the database accessible only within your VNet (or peered VNets), eliminating public IP dependencies entirely.

• How to implement:
  1. Create a private endpoint for your Azure SQL Database in your target VNet.
  2. Ensure your pipeline’s agent (either self-hosted in the same VNet, or a managed agent connected via Azure DevOps VNet integration) can reach the private endpoint.
  3. Optionally disable public network access for the SQL Database to lock it down completely.
• Pros: Zero public exposure, most secure option, no IP management overhead.
• Cons: Requires configuring private DNS zones and VNet peering (if using multiple VNets), with a slightly more complex initial setup.

4. Temporary Firewall Rule (Emergency Only) #

If you need a quick fix for a one-off pipeline run, you can dynamically add and remove the pipeline’s current public IP from the SQL firewall during execution.

• How to implement:
  1. Add a pipeline step to fetch the current agent’s public IP:

     AGENT_IP=$(curl -s https://api.ipify.org)
     

  2. Create a temporary firewall rule using Azure CLI:

     az sql server firewall-rule create --resource-group <rg-name> --server <sql-server-name> --name "PipelineTempRule" --start-ip-address $AGENT_IP --end-ip-address $AGENT_IP
     

  3. Run your SQL-related tasks.
  4. Add a final step to delete the temporary rule (use the always() condition to ensure it runs even if the pipeline fails):

     az sql server firewall-rule delete --resource-group <rg-name> --server <sql-server-name> --name "PipelineTempRule"
     

• Pros: Fast to set up for urgent needs.
• Cons: Less secure (temporarily opens your SQL DB to a single public IP), relies on an external service to fetch the agent IP.

内容的提问来源于stack exchange，提问作者Noor All Safaet