You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Azure容器应用作业配置托管标识(含AcrPush)拉取镜像认证失败

问题:容器应用作业通过部署栈+Bicep部署时ACR认证失败

我使用部署栈(deployment stacks)结合Bicep部署容器应用作业,执行的部署命令如下:

az stack group create --name ${GEN_APPNAME}-${GEN_ENVIRO}-deploy-stack \
    --resource-group ${GEN_RESOURCE_GROUP} \
    --template-file ${FILE} \
    --parameters ${PFILE} \
    --deny-settings-mode 'none' \
    --verbose

我的Bicep文件配置片段如下:

resource uai 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-07-31-preview' existing = {
  name: miName
}
...
resource containerApp 'Microsoft.App/jobs@2023-11-02-preview' = {
  name: containerAppName
  location: location
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${uai.id}': {}
    }
  }
  properties: {
    environmentId: containerAppEnv.id
    configuration: {
      replicaTimeout: 43200
      triggerType: 'Manual'

      registries: [
        {
          server: containerRegistryName
          identity: uai.id
        }
      ]
    }
...

该托管标识已配置AcrPush权限(包含pull权限),但执行部署命令时出现以下错误:

Code: InvalidParameterValueInContainerTemplate Message: The following field(s) are either invalid or missing. Field 'template.containers.llexport.image' is invalid with details: 'Invalid value: "xxxx.azurecr.io/llexport:7cfedd7": GET https:?scope=repository%3Allexport%3Apull&service=xxxx.azurecr.io: UNAUTHORIZED: authentication required, visit https://aka.ms/acr/authorization for more information.';.

奇怪的是,此配置之前可用,且在非作业类型的容器应用中仍正常工作。我已尝试以下排查动作:

  • 用相同方式部署MS Hello World
  • 在Bicep文件中硬编码实际标识ID
  • 验证托管标识存在且已配置AcrPull权限
  • 手动创建另一个带Contributor权限的托管标识并尝试
  • 验证注册表已启用ARM受众令牌认证

使用以下AZ CLI命令可成功部署该容器作业:

az containerapp job create --name llexport \
    --resource-group rg-xxx-uat \
    --environment acaenv-xxx-xxx-uat \
    --image xxx.azurecr.io/llexport:$HASH \
    --registry-server xxx.azurecr.io \
    --query properties.template \
    --output yaml > llexport-config-output.yml \
    --registry-identity id-xxx-uat \
    --trigger-type "Manual" \
    --replica-timeout 300 \
    --replica-retry-limit 1 \
    --parallelism 1 \
    --replica-completion-count 1 \

补充说明:使用--registry-identity而非--identity时,AZ命令可正常执行;已确认ARM受众令牌已启用。

请问是不是容器应用作业的相关机制有变更,导致当前配置不再生效?


解决方案

问题核心在于容器应用作业与普通容器应用的注册表身份认证配置逻辑存在差异,结合你提供的信息,可从以下几点修正:

  1. 注册表身份字段的取值要求
    容器应用作业的注册表身份绑定,部分API版本要求使用托管标识的客户端ID而非资源ID。你当前用的uai.id是资源ID,可改为客户端ID尝试:

    registries: [
      {
        server: containerRegistryName
        identity: uai.properties.clientId // 替换为客户端ID
      }
    ]
    
  2. 显式添加资源依赖
    部署栈处理资源时可能存在依赖延迟,需在容器作业资源中显式添加对托管标识的依赖,确保部署时标识已完全就绪:

    resource containerApp 'Microsoft.App/jobs@2023-11-02-preview' = {
      name: containerAppName
      location: location
      dependsOn: [uai] // 新增依赖配置
      // 其余原有配置
    }
    
  3. API版本兼容性调整
    你使用的2023-11-02-preview是预览版API,存在行为变更风险。建议升级到稳定版API(如2024-03-01),稳定版的注册表身份认证逻辑更一致。

  4. 验证注册表身份的独立绑定
    容器应用作业的注册表身份是独立配置项,不依赖全局identity节点的配置。确保registries中的identity字段直接指向有权限的托管标识,无需依赖全局身份的继承。


内容的提问来源于stack exchange,提问作者Pompey Magnus

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.06.26 01:52:11