Глобальная компания использует AWS Control Tower и имеет одну централизованную учетную запись DevOps с CI/CD-пайплайнами, которые развертываются в учетные записи приложений. Проект CodeBuild в централизованной учетной записи DevOps использует роль сервиса и пытается развернуть приложение в кластере EKS в учетной записи приложения. Развертывание завершается с ошибкой Unauthorized, когда CodeBuild пытается получить доступ к кросс-аккаунтному кластеру EKS. Какое изменение исправит ошибку авторизации?

Правильный ответ описывает стандартный и безопасный метод кросс-аккаунтного доступа к ресурсам AWS, особенно к кластерам EKS. Чтобы CodeBuild из централизованной учетной записи DevOps мог развертывать ресурсы в учетной записи приложения, ему необходимо принять роль (assume role) в целевой учетной записи. Это требует, чтобы политика доверия роли в учетной записи приложения разрешала централизованной учетной записи DevOps принимать эту роль (sts:AssumeRole). Кроме того, для доступа к EKS необходимо настроить разрешения IAM и сопоставить роль в ConfigMap aws-auth кластера EKS с соответствующими разрешениями Kubernetes. Неправильные варианты: Изменение политики доверия роли IAM для развертывания в централизованной учетной записи DevOps, чтобы доверять учетной записи приложения, не имеет смысла, так как централизованная учетная запись инициирует действие, а не наоборот. Использование sts:AssumeRoleWithSAML не подходит, так как это для федерации удостоверений, а не для кросс-аккаунтного доступа между AWS аккаунтами. Доверие управляющей учетной записи AWS Control Tower не является прямым решением для предоставления доступа из учетной записи DevOps к учетной записи приложения. Управляющая учетная запись обычно не участвует в прямом развертывании приложений.