Een wereldwijd opererend bedrijf gebruikt AWS Control Tower en heeft één gecentraliseerd DevOps-account met CI/CD-pipelines die implementeren in applicatieaccounts. Een CodeBuild-project in het gecentraliseerde DevOps-account gebruikt een servicerol en probeert een applicatie te implementeren op een EKS-cluster in een applicatieaccount. De implementatie mislukt met Unauthorized wanneer CodeBuild probeert toegang te krijgen tot het cross-account EKS-cluster. Welke wijziging zal de autorisatiefout oplossen?

De correcte optie lost de autorisatiefout op door een cross-account rol aan te maken die CodeBuild kan aannemen. De CodeBuild-servicerol in het DevOps-account zal sts:AssumeRole aanroepen op de nieuwe rol in het applicatieaccount. Deze nieuwe rol moet de benodigde EKS-machtigingen hebben en moet worden toegewezen aan Kubernetes-machtigingen via de aws-auth ConfigMap van het EKS-cluster. De eerste incorrecte optie draait de rollen om: het DevOps-account moet het applicatieaccount niet vertrouwen voor implementatie. De tweede incorrecte optie is onnodig complex en onjuist; AssumeRoleWithSAML is voor federatie, niet voor cross-account toegang. De derde incorrecte optie is onjuist omdat het Control Tower-beheeraccount niet direct betrokken is bij de implementatieautorisatie tussen het DevOps- en applicatieaccount.