A development team uses AWS CodeBuild to run CI/CD pipelines. The CodeBuild projects need to access resources in other AWS accounts, such as pulling code from a CodeCommit repository in a 'Source' account and deploying artifacts to an S3 bucket in a 'Deployment' account. The security team wants to ensure that these cross-account interactions adhere to the principle of least privilege and are auditable. What is the most secure and scalable approach?
- ACreate an IAM role in the 'Source' account and another in the 'Deployment' account, each with a trust policy allowing the CodeBuild service role from the 'Build' account to assume them. Grant minimal necessary permissions to each role.
- BAttach an SCP to the 'Source' and 'Deployment' accounts to explicitly allow CodeBuild access from the 'Build' account.
- CCreate an IAM user in the 'Source' and 'Deployment' accounts with programmatic access keys and configure CodeBuild to use these credentials.
- DConfigure the CodeBuild service role in the 'Build' account to have full administrative access to all AWS resources in the 'Source' and 'Deployment' accounts.
Show answer & explanationAnswer & explanation
Correct answer: A. Create an IAM role in the 'Source' account and another in the 'Deployment' account, each with a trust policy allowing the CodeBuild service role from the 'Build' account to assume them. Grant minimal necessary permissions to each role.
Creating specific IAM roles in the 'Source' and 'Deployment' accounts, each with a trust policy allowing the CodeBuild service role to assume them, and granting only the necessary permissions (e.g., CodeCommit read, S3 write), adheres to the principle of least privilege and enables auditable cross-account access.
Why the other options are wrong
- B. SCPs define maximum permissions or deny actions; they do not grant permissions. An SCP alone cannot facilitate cross-account access for CodeBuild.
- C. Using long-lived access keys is less secure than temporary credentials provided by role assumption and complicates key rotation.
- D. Granting full administrative access violates the principle of least privilege and creates a significant security risk.
Cross-Account Role Assumption
Allows an IAM principal in one AWS account to temporarily access resources in another AWS account by assuming a role.
- Relies on a trust policy in the target account's role, specifying which principals can assume it.
- Provides temporary security credentials, reducing the risk of long-lived access keys.
- Enables granular, least-privilege access across account boundaries.
Memory trick: Think of a 'secure bridge' between accounts, where only authorized 'messengers' (roles) can cross with specific 'delivery instructions' (permissions).