不同资源组中私有AKS与ACR的零信任配置镜像拉取403错误排查求助

针对你遇到的az aks check-acr命令返回403（ACR令牌交换失败）的问题，我整理了以下逐步排查的方向，你可以逐一验证：

1. 确认AKS托管身份的acrPull权限配置正确 #

首先，AKS使用托管身份访问ACR时，需要确保该身份已被正确赋予acrPull角色：

• 获取AKS集群的托管身份ID：

  az aks show -g <你的资源组名> -n <AKS集群名> --query "identity.principalId" -o tsv
  

• 获取ACR的资源ID：

  az acr show -g <你的资源组名> -n containerregistrymaryam.azurecr.io --query id -o tsv
  

• 检查现有角色分配：

  az role assignment list --assignee <AKS托管ID> --scope <ACR资源ID>
  

  如果输出中没有acrPull角色的记录，需要重新添加权限：

  az role assignment create --assignee <AKS托管ID> --role acrPull --scope <ACR资源ID>
  

2. 验证ACR与AKS的私有网络连通性 #

你已经配置了ACR的私有访问，需要确保网络层面没有阻断：

• 在AKS节点上执行DNS解析测试，确认ACR域名指向私有IP：

  nslookup containerregistrymaryam.azurecr.io
  

  如果返回公网IP，说明私有DNS区域或私有端点的配置存在问题，需要检查：
  • ACR的私有端点是否关联到AKS所在的VNet
  • 是否创建了privatelink.azurecr.io的Azure私有DNS区域，并与VNet关联
• 检查ACR的防火墙规则，确认是否允许AKS所在VNet的子网访问（如果ACR设置为仅允许特定网络）

3. 测试AKS托管身份的访问能力 #

直接用AKS的托管身份尝试登录ACR，验证身份本身是否正常：

• 先切换到AKS的托管身份登录：

  az login --identity --username <AKS托管ID>
  

• 尝试登录ACR：

  az acr login -n containerregistrymaryam.azurecr.io
  

  如果登录失败，说明托管身份可能存在状态异常，或者缺少其他必要权限（比如Azure资源管理器的访问权限）

4. 检查命令参数与基础配置 #

• 确认az aks check-acr命令的参数完全正确，比如AKS集群名、资源组、ACR名称是否拼写无误：

  az aks check-acr -n <AKS集群名> -g <资源组名> --acr containerregistrymaryam.azurecr.io
  

• 检查ACR是否启用了管理员账户：虽然托管身份访问不需要管理员账户，但如果ACR的访问策略有其他限制，也可能导致问题

5. 查看Azure活动日志获取详细错误信息 #

登录Azure门户，找到你的ACR资源，进入活动日志，搜索与“token exchange”或“403”相关的事件，这些日志通常会提供更具体的失败原因，比如是权限不足、网络拒绝还是身份验证问题

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