启用专用链接的Azure容器注册表部署容器实例遇鉴权/镜像问题

核心排查方向 #

1. 专用链接DNS解析有效性验证 #

虽然已关联DNS区域，仍需确认ACI所在VNet的DNS配置是否正确指向专用DNS区域：

• 检查ACI的VNet是否已关联privatelink.azurecr.io类型的Azure私有DNS区域
• 在ACI所在子网的虚拟机中执行nslookup <你的ACR名称>.azurecr.io，确认返回结果为ACR专用链接的私有IP。若解析到公网IP，说明DNS配置未生效，ACI会尝试走公网访问ACR，被防火墙拦截。

2. ACI网络配置限制检查 #

• 确认ACI部署在启用专用链接的VNet子网内，且该子网的网络安全组（NSG）、路由表未阻止出站到ACR专用IP的443端口流量
• 若ACI采用公共网络模式（非VNet集成），即使ACR启用专用链接，ACI仍会走公网访问。此时需注意：“信任Microsoft服务”规则可能未覆盖公共网络模式的ACI，这种场景下要么将ACI的出站公网IP加入ACR防火墙允许列表（不推荐，违背专用链接设计初衷），要么改为VNet集成部署。

3. 身份验证权限细节核查 #

管理员账户

• 确认ACR管理员账户处于启用状态，且输入的用户名（ACR名称）、密码无复制错误（如空格、特殊字符遗漏）

用户托管标识（UAMI）

• 确认UAMI已被授予AcrPull角色，且角色作用域直接指向目标ACR资源（避免资源组层级的权限继承问题）
• 检查ARM模板中，ACI的identity配置是否正确关联UAMI，且imageRegistryCredentials的identity字段指向UAMI的完整资源ID，示例配置：

"imageRegistryCredentials": [
  {
    "server": "<你的ACR名称>.azurecr.io",
    "identity": "/subscriptions/<订阅ID>/resourceGroups/<资源组>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<UAMI名称>"
  }
]

服务主体/令牌

• 服务主体需被授予AcrPull角色，且客户端ID、密钥（或证书）未过期
• 令牌需配置pull权限且在有效期内，同时确认令牌作用域覆盖目标镜像仓库或整个ACR

4. ACR专用链接端点状态确认 #

• 在Azure门户检查ACR的专用链接端点，确认状态为已批准，无待批准或拒绝状态
• 确认专用链接关联的VNet、子网与ACI所在VNet/子网一致（或已建立VNet对等互联）

临时验证步骤 #

若上述排查无问题，可尝试以下操作定位根因：

1. 在ACI所在VNet的虚拟机上，使用docker login <你的ACR名称>.azurecr.io（管理员密钥登录）或az acr login --name <ACR名称> --identity（UAMI登录），尝试拉取目标镜像。若虚拟机可成功拉取，说明ACR与VNet连接正常，问题出在ACI配置；若虚拟机也失败，说明VNet或DNS配置存在问题。
2. 查看ACI部署日志：在门户的ACI资源“日志”中提取具体错误信息，区分是unauthorized（权限问题）还是no such image（镜像路径错误或解析问题），缩小排查范围。

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