Мои ACR и AKS находятся в одном каталоге Azure с одной и той же подпиской.
После предоставления доступа ACR Pull к моему субъекту-службе ничего не работало, и по-прежнему возникает эта ошибка.
Error :- Failed to pull image "xx.azurecr.io/xx:latest": rpc error: code = Unknown desc = Error response from daemon: Get https://xx.azurecr.io/v2/xx/manifests/latest: unauthorized: authentication required
да я проверил @4c74356b41
можете предоставить доказательства?
это не означает, что AKS использует SP. вы можете использовать az aks show -n xxx -g yyy
для проверки AKS SP
az aks show --resource-group rg-000 --name demo-cluster --query "servicePrincipalProfile" -o json { "clientId": "0173xxxxxxxxxxxxx" }
тот же идентификатор клиента принадлежит SP в IAM консоли ACR: с доступом acrPull
Из сообщения об ошибке видно, что вы не прошли проверку подлинности, чтобы извлечь образ из Реестра контейнеров Azure.
Для AKS есть два способа получить разрешение на извлечение образа из реестра контейнеров Azure.
Один предоставляет разрешение субъекту-службе, который используется кластером AKS. Подробности можно узнать в Предоставление AKS доступа к ACR. Таким образом, вам нужен только один субъект-служба.
Другой — это предоставление разрешения новому субъекту-службе, который отличается от того, который использовал AKS. Затем вы создаете секрет с субъектом-службой для извлечения образа. Подробности можно узнать в Доступ с секретом Kubernetes.
Это два разных пути, поэтому вы должны убедиться, что в ваших шагах нет ошибки. Чтобы проверить назначение роли для субъекта-службы, выполните следующую команду CLI:
az role assignment list --assignee $SP_ID --role acrpull --scope $ACR_ID
SP_ID зависит от способа, который вы использовали.
Субъект-служба, в которой работал кластер, не является принципалом, как я думал. Чтобы проверить это, выполните следующие шаги.
Выполните команду «az aks show -n имя-кластера-aks-g имя-группы-ресурсов | клиент grep».
Запустите команду «az ad sp credential list --id» — эта команда проверяет, связан ли секрет.
Войдите на лазурный портал.
Перейдите к Реестру контейнеров Azure.
IAM --> Просмотр назначения ролей --> Проверьте, существует ли идентификатор клиента в списке с минимальным доступом «AcrPull». Если не предоставить доступ к SP.
Пожалуйста, проверьте в YAML, видим ли мы правильную аутентификацию или нет.
У нас была другая причина этой ошибки: по умолчанию срок действия субъекта-службы, созданного с помощью кластеров AKS, истекает через год. Инструкции по https://docs.microsoft.com/en-us/azure/aks/update-credentials показывают, как обновить или создать нового принципала.
Вы уверены, что это тот же субъект службы, которому вы предоставили доступ?