Globalna firma korzysta z AWS Control Tower i posiada jedno scentralizowane konto DevOps z potokami CI/CD, które wdrażają aplikacje na kontach aplikacyjnych. Projekt CodeBuild na scentralizowanym koncie DevOps używa roli serwisowej i próbuje wdrożyć aplikację do klastra EKS na koncie aplikacyjnym. Wdrożenie kończy się błędem Unauthorized, gdy CodeBuild próbuje uzyskać dostęp do klastra EKS na innym koncie. Jaka zmiana naprawi błąd autoryzacji?

Poprawna odpowiedź rozwiązuje problem, umożliwiając CodeBuild na koncie DevOps przejęcie roli IAM na koncie aplikacji. Polityka zaufania tej roli na koncie aplikacji musi zezwalać na sts:AssumeRole z konta DevOps. Następnie, ta rola musi mieć odpowiednie uprawnienia do interakcji z klastrem EKS. Kluczowym krokiem jest również zmapowanie tej roli w aws-auth ConfigMap klastra EKS, aby Kubernetes mógł autoryzować działania wykonywane przez tę rolę. Pozostałe opcje są nieprawidłowe: Zmiana polityki zaufania roli na koncie DevOps, aby ufała kontu aplikacyjnemu, nie rozwiąże problemu, ponieważ to konto DevOps próbuje uzyskać dostęp do zasobów na koncie aplikacyjnym, a nie odwrotnie. Użycie sts:AssumeRoleWithSAML jest nieodpowiednie, ponieważ jest przeznaczone do federacji tożsamości z dostawcami tożsamości SAML, a nie do komunikacji między kontami AWS. Ufanie kontu zarządzania AWS Control Tower nie jest prawidłowe, ponieważ to konto DevOps, a nie konto zarządzania, potrzebuje dostępu do klastra EKS.