Setting Service Account Permissions

This page explains how the Container Builder service account works, and how to grant the service account access to other projects.

What is the Container Builder service account?

Container Builder executes your builds using a service account, a special Google account that executes builds on your behalf. The email for the Container Builder service account is [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com.

You can view your project's service accounts via the IAM menu of the GCP Console.

When you enable the Container Builder API, the service account is automatically created and granted the Cloud Container Builder role for your project. This role is sufficient for several tasks, including:

  • Fetching code from your project's Cloud Source Repository
  • Downloading files from a Cloud Storage bucket owned by your project
  • Saving build logs in Cloud Logging
  • Pushing Docker images to Container Registry
  • Pulling base images from Container Registry

The service account performs these actions only as required to execute your build. For example, the service account does not fetch code from your Cloud Source Repository unless you instruct it to do so.

Granting additional access

The service account's default permissions do not allow the account to perform certain actions, such as deploying to App Engine or managing Compute Engine, Kubernetes Engine resources, or accessing a Cloud Storage bucket.

You can enable your service account to perform these actions by granting the account additional IAM roles.

To grant an IAM role to a Container Builder service account:

  1. Open the IAM page in GCP Console

    Open the IAM page

  2. Select your project and click Continue.

  3. In the list of members look for your Container Builder service account named [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com, where [PROJECT_NUMBER] is your GCP project project number.
  4. Click the pencil icon in that row.
  5. Click Add another role, select a role from the drop-down, and click Save.

Pull private images from other Google Cloud Platform projects

You can grant permissions to pull private images from another Cloud Platform project, provided that the service account has access to the project. For example, you might want to execute a build in Project A that can pull images from Project B.

gsutil

To grant your service account these permissions, run the following commands in your shell or terminal window, where [PROJECT_NUMBER_A] is the project number of PROJECT A and [PROJECT_ID_B] is the project ID of Project B.

  1. Find the name of the Cloud Storage bucket for the registry. To do so, list the buckets:

    gsutil ls
    

    Your Container Registry bucket URL will be listed as gs://artifacts.[PROJECT-ID].appspot.com or gs://[REGION].artifacts.[PROJECT-ID].appspot.com.

  2. Grant permissions for Project A's service account to read Project B's objects:

    gsutil acl ch -r -u [PROJECT_NUMBER_A]@cloudbuild.gserviceaccount.com:R \
        gs://artifacts.[PROJECT_ID_B].appspot.com
    
  3. Grant permissions for Project A's service account to read Project B's bucket:

    gsutil acl ch    -u [PROJECT_NUMBER_A]@cloudbuild.gserviceaccount.com:R \
        gs://artifacts.[PROJECT_ID_B].appspot.com
    
  4. Update Project B's default ACL so that Project A's service account has read permissions for objects that are created after you perform steps 1 and 2 above:

    gsutil defacl ch -u [PROJECT_NUMBER_A]@cloudbuild.gserviceaccount.com:R \
        gs://artifacts.[PROJECT_ID_B].appspot.com
    

console

For instructions on granting permissions using the GCP Console, see Creating and Managing Access Control Lists.

Push private images to other Google Cloud Platform projects

You can grant permissions to push private images to another Cloud Platform project, provided that the service account has access to the project. For example, you might want to execute a build in Project A that can push images to Project B.

gsutil

To grant your service account these permissions, run the following commands in your shell or terminal window, , where [PROJECT_NUMBER_A] is the project number of PROJECT A and [PROJECT_ID_B] is the project ID of Project B.

  1. Find the name of the Cloud Storage bucket for the registry. To do so, list the buckets:

    gsutil ls
    

    Your Container Registry bucket URL will be listed as gs://artifacts.[PROJECT-ID].appspot.com or gs://[REGION].artifacts.[PROJECT-ID].appspot.com.

  2. Grant permissions for Project A's service account to update Project B's objects:

    gsutil acl ch -r -u [PROJECT_NUMBER_A]@cloudbuild.gserviceaccount.com:W \
        gs://artifacts.[PROJECT_ID_B].appspot.com
    
  3. Grant permissions for Project A's service account to write to Project B's bucket:

    gsutil acl ch    -u [PROJECT_NUMBER_A]@cloudbuild.gserviceaccount.com:W \
        gs://artifacts.[PROJECT_ID_B].appspot.com
    
  4. Update Project B's default ACL so that Project A's service account has write permissions for objects that are created after you perform steps 1 and 2 above:

    gsutil defacl ch -u [PROJECT_NUMBER_A]@cloudbuild.gserviceaccount.com:W \
        gs://artifacts.[PROJECT_ID_B].appspot.com
    

console

For instructions on granting permissions using the GCP Console, see Creating and Managing Access Control Lists.

Troubleshooting

If you find 403 (access denied) errors in your build logs, try the following steps:

  • Disable the Container Builder API and re-enable it. Doing so should give your service account access to your project again.
  • Run the above commands again.

What's next

Was this page helpful? Let us know how we did:

Send feedback about...

Cloud Container Builder