Azure存储账户：管道中防火墙变更后访问为何不稳定？

结合你描述的场景——同一代理、同一作业中，脚本测试存储账户Blob访问成功，但后续Terraform init报403，甚至同一脚本内上传成功删除失败，核心原因大概率是Azure存储账户的防火墙/权限机制存在异步生效或缓存延迟，以下是具体排查方向和解决办法：

1. 防火墙规则的异步生效延迟 #

Azure存储账户的防火墙规则配置后，需要同步到全球的存储节点，这个过程并非实时完成。你的测试脚本可能在部分节点生效后就判定成功，但Terraform发起请求时，目标存储节点的规则还未完成同步，导致403拦截。

• 解决：
  • 延长测试后的等待时间（比如1-2分钟），不要测试成功后立即执行Terraform
  • 修改重试脚本，改为连续多次测试成功（比如连续3次上传/下载都成功）再退出，确保规则在多数节点已生效

2. 代理出口IP的一致性问题 #

虽然是同一代理，但部分云托管代理（比如Azure DevOps Hosted Agent）可能存在多出口IP，或者脚本获取的IP并非Terraform实际使用的出口IP：

• 排查：在Terraform init步骤前，添加命令打印当前代理的公网IP（比如Invoke-RestMethod http://ifconfig.me/ip），和脚本中添加到防火墙的IP对比
• 解决：如果代理有多个固定出口IP，将所有IP都添加到存储账户防火墙规则中；若为动态IP，确保脚本和Terraform步骤使用完全相同的方式获取IP

3. Azure存储的权限检查缓存 #

Azure存储的权限验证结果会有短期缓存，即使防火墙规则已添加，之前的拒绝请求缓存可能还未过期，导致Terraform请求被拦截：

• 解决：在测试成功后，增加一段强制等待（比如30秒），让缓存过期后再执行Terraform操作

4. 身份权限的细微差异 #

脚本测试和Terraform可能使用了相同的身份，但存在权限范围的差异：

• 排查：确认脚本使用的身份（比如Azure CLI登录的服务主体）和Terraform配置的身份（比如ARM_ACCESS_KEY或服务主体）完全一致，且该身份拥有存储账户Blob数据 Contributor或更高权限
• 解决：统一身份配置，比如在作业中设置相同的环境变量供脚本和Terraform使用

5. 防火墙规则的配置范围问题 #

存储账户防火墙规则可能只开放了部分服务或资源：

• 排查：检查防火墙规则是否允许了所有必要的服务（Blob、File等，Terraform状态存储主要依赖Blob，但可能需要访问容器列表），且规则的IP范围正确（没有遗漏端口或服务）
• 解决：将规则的服务范围设置为全部服务，确保Terraform所有相关请求都能被允许

内容的提问来源于stack exchange，提问作者Matt M