技术咨询：为CodeBuild配置CloudFormation/SAM最小权限角色策略，需创建堆栈（create-stack）的通用操作集

Great question! There’s no one-size-fits-all "universal" policy set, but we can break this down into core CloudFormation permissions for CodeBuild plus a critical IAM delegation step that’s key to minimizing privileges. The key insight here is separating two distinct roles to avoid overgranting:

1. The CodeBuild service role: This is what CodeBuild uses to trigger CloudFormation and manage the stack lifecycle. It doesn’t need direct permission to create all your infrastructure resources.
2. The CloudFormation execution role: This is the role CloudFormation itself assumes to provision resources defined in your template. This is where you grant specific resource creation permissions (e.g., dynamodb:CreateTable, s3:CreateBucket), not the CodeBuild role.

Core Permissions for the CodeBuild Role #

Here’s the minimal set of permissions CodeBuild needs to successfully run create-stack:

• CloudFormation lifecycle operations:

  • cloudformation:CreateStack: Required to initiate stack creation.
  • cloudformation:DescribeStacks: Useful for CodeBuild to check stack status post-creation (e.g., verify it reached CREATE_COMPLETE).
  • cloudformation:DescribeStackEvents: Optional but helpful for debugging if stack creation fails (lets CodeBuild pull detailed event logs).
  • Add cloudformation:UpdateStack/cloudformation:DeleteStack only if your pipeline includes those specific steps.

• IAM delegation (critical):

  • iam:PassRole: Allows CodeBuild to pass the CloudFormation execution role to the CloudFormation service. You must restrict this to your specific execution role ARN and limit it to the CloudFormation service using a condition (to prevent privilege escalation risks).

• Template access (if applicable):

  • s3:GetObject: If your CloudFormation/SAM template is stored in an S3 bucket, CodeBuild needs permission to fetch it. Restrict this to the specific bucket/path where your templates live.

Example Policy for CodeBuild #

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudformation:CreateStack",
        "cloudformation:DescribeStacks",
        "cloudformation:DescribeStackEvents"
      ],
      "Resource": "arn:aws:cloudformation:*:123456789012:stack/YourStackPrefix-*/*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::123456789012:role/YourCloudFormationExecutionRole",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "cloudformation.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-template-bucket/path/to/templates/*"
    }
  ]
}

Key Notes for Maximizing Minimalism #

• Restrict resources everywhere: Always scope permissions to specific stack ARNs, S3 objects, and IAM roles (avoid wildcard * wherever possible). For example, use a stack prefix like YourStackPrefix-* to let CodeBuild manage only stacks matching that naming pattern.
• Keep execution permissions focused: The CloudFormation execution role should only have permissions to create/update/delete the exact resources defined in your template. As you noted, CloudFormation never needs data-write operations like dynamodb:PutItem—it only needs resource management actions like dynamodb:CreateTable.
• SAM-specific tweaks: If you’re using SAM, you might need additional permissions like serverlessrepo:CreateCloudFormationTemplate if referencing SAM apps from the Serverless Application Repository, but these can still be scoped to specific resources.

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