Orion Retail stores database credentials in AWS Secrets Manager in Account B, encrypted with a customer managed KMS key in Account B. A microservice running in Account A (role: arn:aws:iam::111111111111:role/OrdersAppRole) needs read-only access to the secret. The team added an IAM policy to the role allowing secretsmanager:GetSecretValue on the secret ARN but still receives AccessDenied errors from KMS. What should the security team do to grant least-privilege cross-account access?

The correct solution requires two steps for cross-account access to a secret encrypted with a customer-managed KMS key. First, the secret's resource-based policy in Account B must grant secretsmanager:GetSecretValue to the OrdersAppRole in Account A. This allows the role to access the secret itself. Second, the KMS key policy in Account B must explicitly allow kms:Decrypt for the OrdersAppRole. This is crucial because Secrets Manager uses KMS to decrypt the secret value, and cross-account decryption requires an explicit grant in the KMS key policy. Replicating the secret to Account A (option 2) is not least-privilege and introduces data duplication. Creating VPC interface endpoints (option 3) secures network traffic but doesn't address the IAM and KMS permissions. Only updating the OrdersAppRole IAM policy (option 4) is insufficient because resource-based policies on the secret and KMS key are also necessary for cross-account access.