Free tool

CodeBuild service role policy generator

Pick the services your CodeBuild calls and get the service role it needs — scoped to the right ARNs, with the reason behind every action.

1. Which thing needs the role?

The compute that makes the calls. It assumes the role; everything else is a resource the role points at.

Principal

Changing this opens that principal’s own page.

2. What does it call?

Only connections the knowledge base records IAM requirements for. Tick what your CodeBuild actually talks to.

CodeArtifactDuring a build, CodeBuild authenticates to a CodeArtifact repository to pull private packages (npm, pip, Maven, NuGet) — and optionally publish built packages back to it
CodeCommitCodeBuild clones the source code (and buildspec) for the project from a CodeCommit repository at the start of a build
ECRCodeBuild pulls a custom build-environment image from a private ECR repository to run the build in, and/or builds a Docker image during the build and pushes it back to ECR
S3CodeBuild uploads build output artifacts to an S3 bucket, reads/writes an S3 build cache, and can pull the source itself from an S3 object (zip or folder)
Secrets ManagerCodeBuild pulls sensitive build values — private-registry credentials, API tokens, signing keys — from Secrets Manager instead of storing them as plaintext environment variables

3. Fill in your account (optional)

Leave these blank and the ARNs keep visible placeholders, so a half-finished policy fails instead of quietly granting more than you meant.

Region

Account ID

Role name

Your role

Nothing selected yet, so the role below can be assumed but grants nothing. Tick a service above.

identity-policy.json

{
  "Version": "2012-10-17",
  "Statement": []
}

trust-policy.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CodeBuildAssumeRole",
      "Effect": "Allow",
      "Principal": {
        "Service": "codebuild.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Before you apply this

These are the actions this integration typically needs — not a least-privilege proof. After you deploy, narrow the policy with IAM Access Analyzer, which generates one from the calls the principal actually made.
No permissions were generated. The role below can be assumed but grants nothing — pick at least one service this principal calls.

Worth knowing about a CodeBuild service role

Every CodeBuild project also needs to write its build logs: logs:CreateLogGroup, logs:CreateLogStream and logs:PutLogEvents on the project's log group. AWS generates that as an inline policy rather than a managed one, so it is not attached above. TODO: verify the exact log-group ARN shape for your project.
The service role's credentials are available inside the build automatically — do not bake access keys into the buildspec or the image. (Knowledge base, CodeBuild → S3.)
The trust policy lets any codebuild.amazonaws.com resource in any account assume this role. AWS recommends narrowing it with an aws:SourceArn (and aws:SourceAccount) condition naming the specific resource that may assume it — add that once you know the ARN.

Grounded in the same data that validates diagrams

Design Beaver models AWS connections so it can tell you when a diagram is wrong. Part of that model is which IAM actions each integration needs and why — researched against AWS documentation, not inferred. This tool reads that data directly, which is why it can explain every statement instead of just emitting one.

It also means the tool knows what it doesn’t know. A connection the knowledge base has no IAM data for is skipped and named, never filled in with a plausible guess. Where an action comes from somewhere other than the knowledge base, it is labelled.

What a CodeBuild service role can be scoped to

CodeBuild assumes this role through the codebuild.amazonaws.com service principal. These are the 5 connections the knowledge base records IAM requirements for:

CodeBuild → CodeArtifact

During a build, CodeBuild authenticates to a CodeArtifact repository to pull private packages (npm, pip, Maven, NuGet) — and optionally publish built packages back to it

codeartifact:GetAuthorizationTokencodeartifact:GetRepositoryEndpointcodeartifact:ReadFromRepositorysts:GetServiceBearerToken

Grant the service role codeartifact:GetAuthorizationToken, codeartifact:GetRepositoryEndpoint and codeartifact:ReadFromRepository, PLUS sts:GetServiceBearerToken (required to call CodeArtifact's GetAuthorizationToken) — the buildspec runs the CodeArtifact login command in its pre_build phase to configure the package manager

To publish packages from the build, additionally grant codeartifact:PublishPackageVersion (and the associated package/version actions) on the target repository

CodeBuild → CodeCommit

CodeBuild clones the source code (and buildspec) for the project from a CodeCommit repository at the start of a build

codecommit:GitPull

Grant the CodeBuild project's service role codecommit:GitPull on the source repository so it can clone the code; CodeBuild uses the service role's credentials via the git credential helper, so no stored git username/password is needed

The CodeCommit repository is set as the project's primary source (or a secondary source), and the repository must contain the buildspec (or the project supplies an inline/S3 buildspec instead)

CodeBuild → ECR

CodeBuild pulls a custom build-environment image from a private ECR repository to run the build in, and/or builds a Docker image during the build and pushes it back to ECR

ecr:GetAuthorizationTokenecr:BatchCheckLayerAvailabilityecr:GetDownloadUrlForLayerecr:BatchGetImageecr:InitiateLayerUploadecr:UploadLayerPartecr:CompleteLayerUploadecr:PutImage

For a custom ECR build image, grant the service role the pull actions ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, ecr:BatchCheckLayerAvailability and ecr:GetAuthorizationToken; when the ECR repository is in a different account, also attach an ECR repository policy allowing CodeBuild

To push a built image, additionally grant ecr:InitiateLayerUpload, ecr:UploadLayerPart, ecr:CompleteLayerUpload and ecr:PutImage; the buildspec runs a docker login using the token from ecr:GetAuthorizationToken before pushing

Enable privileged mode on the project if the build runs Docker (docker build) itself, since that needs the Docker daemon inside the build container

CodeBuild → S3

CodeBuild uploads build output artifacts to an S3 bucket, reads/writes an S3 build cache, and can pull the source itself from an S3 object (zip or folder)

s3:GetObjects3:GetObjectVersions3:PutObjects3:GetBucketAcls3:GetBucketLocation

Grant the project's service role the S3 actions on the relevant buckets: s3:PutObject to write artifacts/cache, s3:GetObject / s3:GetObjectVersion to read the S3 source and cache, and s3:GetBucketAcl / s3:GetBucketLocation for bucket verification. Cross-account artifact buckets also need s3:PutObjectAcl / s3:PutBucketAcl so the receiving account can read the object

The service role's credentials are picked up automatically inside the build — do not bake access keys into the buildspec or image

CodeBuild → Secrets Manager

CodeBuild pulls sensitive build values — private-registry credentials, API tokens, signing keys — from Secrets Manager instead of storing them as plaintext environment variables

secretsmanager:GetSecretValue

Grant the service role secretsmanager:GetSecretValue on the specific secret. Reference the secret either as a SECRETS_MANAGER-type environment variable on the project, or with a secrets-manager reference key in the buildspec's env/secrets-manager block; CodeBuild substitutes the value at build start

Prefer this over PLAINTEXT environment variables for anything sensitive — plaintext env vars are visible in the console and CLI

Generate a role for something else

Questions

Where do the actions come from?

From Design Beaver's AWS knowledge base — the same data its validation engine uses to check architecture diagrams. Each connection between two services records the IAM actions that integration needs and the reason it needs them, researched against AWS documentation. Nothing is generated by a model, and the tool refuses to guess: a service pair the knowledge base has no IAM data for is skipped and reported rather than invented.

Is this a least-privilege policy?

No, and it says so on every policy it generates. These are the actions the integration typically needs — a sound starting point, not proof of minimum access. After you deploy, narrow it with IAM Access Analyzer, which generates a policy from the calls the principal actually made. That is the only way to get a genuinely least-privilege result.

How is this different from the other IAM policy generators?

Most of them start from the action catalogue: search 20,000 actions across 400 services and pick the ones you want, which assumes you already know the answer. This one starts from the architecture — this Lambda calls DynamoDB and SQS — and works out the actions from there. It also scopes each statement to the right ARN, so s3:ListBucket lands on the bucket while s3:GetObject lands on the objects inside it.

Does anything I type leave my browser?

No. The generator runs entirely client-side. Bucket names, table names, account IDs and ARNs are never sent anywhere, and there is no signup.

Why are there two policies?

AWS needs both. The trust policy says who may assume the role — the service principal, like lambda.amazonaws.com. The identity policy says what the role may then do. A role with permissions but no trust policy cannot be assumed by anything, and a role with trust but no permissions can be assumed but does nothing.

Draw it instead, and the role attaches itself

Design Beaver knows which connections need a role because it checks them as you draw. Drop an IAM Role node onto a function and the warnings it resolves disappear. Free, in your browser — sign in with Google or GitHub to save your work.

Prefer email? Get new features in your inbox: