Azure DevOps流水线获取Key Vault中SAS Token时报错求助

针对你遇到的Azure DevOps流水线中Terraform init任务报错##[error]Get secrets failed. Error: Could not fetch access token for Azure. Verify if the Service Principal used is valid and not expired..，结合你已排除的因素，可从以下方向排查解决：

1. 确保Key Vault密钥已提前注入环境变量 #

TerraformCLI任务执行前，必须先通过AzureKeyVault@2任务拉取sas_token等密钥，否则$(sas_token)会是未解析的空值，触发Terrafall fallback到服务主体认证逻辑。添加前置任务示例：

- task: AzureKeyVault@2
  displayName: '拉取Key Vault密钥'
  inputs:
    azureSubscription: '<你的Azure服务连接名称>'
    KeyVaultName: '<你的Key Vault名称>'
    SecretsFilter: 'sas_token,storageaccount,container_name,key'

2. 强制Terraform使用SAS Token而非服务主体认证 #

将SAS Token直接传入backend配置，优先级高于环境变量ARM_SAS_TOKEN，避免任务默认的SP认证干扰。修改TerraformCLI任务的commandOptions：

commandOptions: >
  -backend-config=storage_account_name=$(storageaccount)
  -backend-config=container_name=$(container_name)
  -backend-config=key=$(key)
  -backend-config=sas_token=$(sas_token)

同时移除env块中的ARM_SAS_TOKEN配置，减少冲突可能性。

3. 检查TerraformCLI任务的服务连接配置 #

若任务中指定了azureSubscription参数，TerraformCLI会自动使用该服务连接的SP认证Azure，与SAS Token的认证方式冲突。确保任务中未设置该参数：

# 移除或注释此行（如果存在）
# azureSubscription: '<你的服务连接名>'

4. 验证SAS Token的实际权限 #

即使Key Vault能正常拉取sas_token，仍需确认该Token具备对应存储账户的Blob容器读写权限。用Azure CLI手动验证：

az storage container list --account-name <你的存储账户名> --sas-token "$(sas_token)"

若命令失败，需重新生成包含正确权限（如Object resource type、Container级别读写）的SAS Token。

5. 清理代理缓存（自托管代理场景） #

若使用自托管代理，代理机器可能缓存旧的SP令牌，干扰认证逻辑。在TerraformCLI任务前添加清理步骤：

- script: az account clear
  displayName: '清理Azure CLI缓存凭据'

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