An application running on Amazon EKS needs confidential credentials stored in Secrets Manager. The secrets are encrypted with a customer-managed KMS key. A Kubernetes service account for a third-party tool provides the secrets to applications by assuming an IAM role created to access Secrets Manager. The service account receives a 403 Forbidden when attempting to retrieve secrets. What is the root cause?

The correct answer is that the KMS customer-managed key's key policy does not permit the IAM role assumed by the Kubernetes service account to use the key. When secrets encrypted with a customer-managed KMS key are accessed, both the IAM identity accessing the secret and the KMS key policy must explicitly allow decryption. The Kubernetes service account, through its assumed IAM role, is the entity attempting to retrieve the secret. Therefore, its associated IAM role needs permission to use the KMS key for decryption. The IAM role attached to the EKS cluster lacking permissions is incorrect because the service account, not the cluster's role, is directly accessing the secrets. The KMS key policy not permitting the EKS cluster IAM role is incorrect for the same reason—the service account's role is the relevant identity. The IAM role assumed by the Kubernetes service account not having permission to access the EKS cluster is incorrect because the issue is with accessing Secrets Manager and decrypting secrets, not with EKS cluster access.