AzureCLI Task Intermittently Bypasses Proxy on Self-Hosted Linux Agent (WIF/OIDC) #402

Summary

We are observing inconsistent proxy behavior in AzureCLI@2 / AzureCLI@3 tasks when running pipelines on a self-hosted Azure DevOps Linux agent in a restricted network environment.

The environment requires all outbound traffic to go through an HTTP proxy (localhost:3128), with no direct internet access allowed.

However, some Azure service connections work correctly through the proxy, while others (configured identically) bypass the proxy and fail.

Environment

• Self-hosted Linux agent
• Proxy: Local NTLM proxy (localhost:3128)
• Pipeline task: AzureCLI@2 / AzureCLI@3
• Authentication: AzureRM Service Connection using Workload Identity Federation (OIDC)

Expected Behavior

All AzureCLI task executions should:

• Route outbound traffic via the configured proxy
• Successfully connect to endpoints such as dev.azure.com
• Complete authentication using OIDC/WIF

Actual Behavior

Working Service Connection

• AzureCLI task authenticates successfully
• Proxy is used correctly
• Logs (NODE_DEBUG=net) show:

  createConnection localhost:3128 → proxy tunnel → dev.azure.com:443
  

Failing Service Connection

• AzureCLI task fails during initial authentication phase
• Proxy is bypassed
• Logs show a direct connection attempt:

  createConnection dev.azure.com:443
  

• Since direct internet access is blocked → connection fails (timeout / TLS error)

Key Observations

1. Failure occurs before script execution

   • The issue happens during the built-in AzureCLI authentication phase
   • User scripts are never reached

2. Proxy works outside AzureCLI task

   • Tools like curl, bash scripts, and direct OIDC calls correctly use the proxy

3. Service connections are identically configured

   • Created via Terraform
   • No visible configuration differences

Root Cause Analysis (from Engineering Investigation)

• The AzureCLI task internally uses a REST client library that evaluates proxy bypass logic using the full URL string (character-by-character) rather than just the hostname.
• The environment includes a no_proxy configuration with patterns like:

  10.*, 192.*, 127.*
  

• During authentication, requests include a service connection identifier (GUID) in the URL.

Issue Trigger:
If the GUID contains a sequence such as "10", the library incorrectly matches it against the no_proxy pattern.

Outcome:

• Request is misclassified as internal traffic
• Proxy is bypassed unintentionally
• Connection fails in restricted environments

Impact

• Non-deterministic behavior depending on service connection ID
• Identical configurations produce different outcomes
• Breaks pipeline reliability in restricted network environments

Ask

We request a fix to ensure:

• Proxy evaluation is performed only against the hostname, not the full URL
• no_proxy matching does not incorrectly trigger based on GUID values in the request

This issue leads to unpredictable failures and should be addressed to ensure consistent and reliable proxy handling in AzureCLI tasks.

Please find the RCA detail as per investigation:

1. Failure scenario
   AzureCLI@2/@3 fails during WIF authentication on a self-hosted Linux agent behind a proxy, with requests bypassing the proxy and resulting in ECONNRESET.

2. Expected vs actual behavior
   All outbound traffic should go via localhost:3128, but one OIDC token request is sent directly to dev.azure.com:443, causing network rejection.

3. Trigger point in flow
   Failure occurs during OIDC token generation (createOidcToken) where the POST request includes the service connection GUID in the URL query string.

4. Key dependency behavior
   typed-rest-client (used via azure-devops-node-api) determines proxy usage using the NO_PROXY environment variable.

5. Root defect
   NO_PROXY entries are treated as raw, unanchored regex patterns and matched against the entire request URL (not just hostname).

6. Misconfiguration interaction
   Customer used curl-style patterns like 10.*, 192.168.*, which become regex /10.*/i, matching any occurrence of 10 anywhere in the URL.

7. Why only one service connection fails

   • Failing SC GUID contains substring 10 → regex match → proxy bypass
   • Working SC GUID does not → proxy is correctly used

8. Failure mechanism
   Regex match → proxy bypass → direct socket to dev.azure.com → blocked by network → ECONNRESET before task execution.

9. Why other attempts failed

   • Setting HTTP_PROXY/HTTPS_PROXY doesn’t help because bypass logic overrides it
   • .proxybypass and task flags don’t affect typed-rest-client behavior
   • Issue is independent of tenant, auth, or SC configuration

10. True root cause summary
    Library defect in typed-rest-client: improper handling of NO_PROXY (regex-based, full URL match instead of host-only match), leading to unintended proxy bypass based on GUID content.