In this article, I will go through the permissions required for your team members to use the Cloud Build in your project, and which Predefined roles you could use for that.
Required Permissions
First of all, let’s review which permissions your team members will need.
The users who access the Cloud Build API will need to have the following permissions:
storage.buckets.get
storage.buckets.list
storage.objects.create
serviceusage.services.use
The storage permissions are required as Cloud Build pushes its logs into the Google Cloud Storage, while serviceusage.services.use is needed since it enables you to consume quota and billing for the project.
Besides the permissions mentioned above, your team will also need the obvious ones like:
cloudbuild.builds.create
cloudbuild.builds.update
cloudbuild.builds.get
cloudbuild.builds.list
Predefined Roles
The following roles can grant your team the permissions mentioned above:
(storage.buckets.get and storage.buckets.list)
roles/storage.admin
roles/viewer
(storage.objects.create)
roles/storage.objectCreator
(serviceusage.services.use)
roles/serviceusage.serviceUsageConsumer
And, of course, roles/cloudbuild.builds.editor
to create and cancel builds.
The Access Denied Error
Due to the known issue with the Cloud Build logs, your team members will still be experiencing the Access Denied error unless they have one of the Basic roles (Viewer/Editor/Owner).
This error is driven by not having access to the Cloud Build logs stored in GCS - they are stored in a Google-managed bucket that is available for Basic roles only.
This doesn't affect the builds themselves but their logs - your team will still be able to use the Cloud Build without having a Viewer/Editor/Owner role.
The Access Denied Error: Solution
Let's see how to avoid the Access Denied error without giving the users a Basic role.
As mentioned previously, the root cause of that error is that Cloud Build stores logs in a Google-managed bucket by default.
However, we are not obliged to use that particular
bucket and can specify one of our own with the following flag:
--gcs-log-dir=gs://<BUCKET_NAME>/<SUBDIRECTORY>
Note that you will need to specify the subdirectory for the bucket of your choice. Otherwise you will run into the following error:
ERROR: (gcloud.builds.submit) wrong collection: expected [storage.buckets], got [storage.objects]
Top comments (0)