Ein globales Unternehmen nutzt AWS Control Tower und verfügt über ein zentralisiertes DevOps-Konto mit CI/CD-Pipelines, die in Anwendungskonten bereitgestellt werden. Ein CodeBuild-Projekt im zentralisierten DevOps-Konto verwendet eine Servicerolle und versucht, eine Anwendung in einem EKS-Cluster in einem Anwendungskonto bereitzustellen. Die Bereitstellung schlägt mit „Unauthorized“ fehl, wenn CodeBuild versucht, auf den kontoübergreifenden EKS-Cluster zuzugreifen. Welche Änderung behebt den Autorisierungsfehler?

Die korrekte Option beschreibt den Standardansatz für kontoübergreifenden Zugriff auf EKS-Cluster. Das zentrale DevOps-Konto muss eine Rolle im Anwendungskonto annehmen können, die über die notwendigen Berechtigungen für den EKS-Cluster verfügt. Die Vertrauensrichtlinie dieser Rolle im Anwendungskonto muss dem Prinzip des DevOps-Kontos (der CodeBuild-Servicerolle) erlauben, sts:AssumeRole aufzurufen. Zusätzlich müssen die EKS-Berechtigungen dieser Rolle in der aws-auth ConfigMap des EKS-Clusters Kubernetes-Rollen zugewiesen werden, um die Autorisierung innerhalb des Clusters zu ermöglichen. Die erste falsche Option ist unzutreffend, da das DevOps-Konto nicht dem Anwendungskonto vertrauen muss; vielmehr muss das Anwendungskonto dem DevOps-Konto vertrauen. Die zweite falsche Option ist falsch, da sts:AssumeRoleWithSAML für Verbundidentitäten verwendet wird, nicht für den direkten kontoübergreifenden Zugriff zwischen AWS-Konten. Die dritte falsche Option ist falsch, da das Vertrauen zum AWS Control Tower-Verwaltungskonto nicht direkt den Zugriff vom DevOps-Konto auf den EKS-Cluster im Anwendungskonto ermöglicht. Das Vertrauen muss direkt zwischen dem Quell- und Zielkonto hergestellt werden.