主账户CI用户跨子账户（Dev/Test/Production）扮演角色执行CloudFormation/Serverless部署的可行性问询

Great question—yes, you absolutely can use your master account's ci_user to assume roles in your Dev, Test, and Production child accounts for deployments. This is actually a recommended AWS best practice, and you don't need to create separate IAM users in each child account to make it work. Let me break down how to set this up, and why it's better than managing per-account users.

How to Implement Cross-Account Role Assumption #

1. Create Deployment Roles in Each Child Account #

First, in every child account, you'll need to create an IAM role that has all the permissions required for your deployment workflow—think permissions for CodeBuild, CodePipeline, CloudFormation, Lambda, and any other services you're using.

The key part here is the role's trust policy, which needs to explicitly allow your master account's ci_user to assume it. Here's a simplified example of what that trust policy might look like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::YOUR_MASTER_ACCOUNT_ID:user/ci_user"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Make sure to replace YOUR_MASTER_ACCOUNT_ID with your actual master account ID, and customize the role's permission policy to match your deployment needs.

2. Grant ci_user Permission to Assume These Roles #

Back in your master account, update the IAM policy attached to ci_user to let them call sts:AssumeRole for each of the child account roles you just created. Example policy snippet:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": [
        "arn:aws:iam::DEV_ACCOUNT_ID:role/DevDeploymentRole",
        "arn:aws:iam::TEST_ACCOUNT_ID:role/TestDeploymentRole",
        "arn:aws:iam::PROD_ACCOUNT_ID:role/ProdDeploymentRole"
      ]
    }
  ]
}

Again, swap in your actual child account IDs and role names here.

3. Configure Your CI/CD Tools to Use the Assumed Roles #

For CodeBuild: You can either specify the child account's role ARN directly in the project settings (under Environment > Service Role), or use commands in your buildspec to call aws sts assume-role, export the temporary credentials, and use those for subsequent deployment steps.

For CodePipeline: Set up cross-account actions in your pipeline that reference the child account's role. This lets the pipeline execute deployment steps in the target child account using the assumed role, all triggered from your master account.

Why This Beats Per-Account IAM Users #

• Centralized Identity Management: You only have to manage ci_user in one place—no need to replicate users, permissions, and MFA settings across three accounts.
• Less Credential Overhead: Fewer IAM users mean fewer access keys to rotate and secure, reducing your attack surface.
• Unified CI/CD Workflow: You can keep your entire deployment pipeline in the master account, making it easier to maintain consistent processes across all environments.

Edge Cases Where Per-Account Users Might Make Sense #

While role assumption is the way to go for most scenarios, there are rare exceptions:

• If your compliance rules require separate, account-specific identities (though role assumption still satisfies most auditing requirements when properly logged).
• If you're using a third-party tool that doesn't natively support AWS role assumption (but most modern CI/CD tools do, including AWS's own CodeBuild/CodePipeline).

内容的提问来源于stack exchange，提问作者steadweb