Una empresa global utiliza AWS Control Tower y tiene una cuenta centralizada de DevOps con pipelines de CI/CD que se implementan en cuentas de aplicaciones. Un proyecto de CodeBuild en la cuenta centralizada de DevOps utiliza un rol de servicio e intenta implementar una aplicación en un clúster de EKS en una cuenta de aplicación. La implementación falla con Unauthorized cuando CodeBuild intenta acceder al clúster de EKS de cuenta cruzada. ¿Qué cambio solucionará el error de autorización?

La opción correcta aborda todos los aspectos necesarios para el acceso entre cuentas a EKS. Primero, la política de confianza del rol de IAM en la cuenta de aplicación debe permitir que la cuenta centralizada de DevOps asuma ese rol (sts:AssumeRole). Segundo, este rol debe tener los permisos de IAM necesarios para interactuar con el clúster de EKS. Finalmente, para que las credenciales asumidas sean reconocidas por Kubernetes, el rol debe mapearse a los permisos de sistema apropiados dentro del ConfigMap aws-auth del clúster de EKS. Las opciones incorrectas fallan porque: La segunda opción invierte la dirección de la confianza y no aborda los permisos de EKS ni el mapeo de Kubernetes. La tercera opción introduce AssumeRoleWithSAML, que no es el mecanismo estándar para la asunción de roles entre cuentas en este escenario y tampoco aborda los permisos de EKS. La cuarta opción hace que el rol de la cuenta de aplicación confíe en la cuenta de administración de Control Tower, lo cual no es relevante para el acceso desde la cuenta centralizada de DevOps.