GCP Permissions Boundary
This page describes how to restrict Release permissions to the GCP integration project(s)
Introduction
For ease of use in an isolated and/or dedicated development project, we recommend that you simply set an "Owner" or Administrative role for the project to avoid unnecessary hiccoughs managing your development clusters. However, for Production or production-like environments and projects, the administrative permissions may be too much to grant and may cause auditing and compliance issues with the excess privileges that are assigned to the project.
Follow this guide to restrict or document permissions that are required for correct functioning of a Release GCP project. As of Jan, 2024.
"Easy Button" Onboarding
If you would like to avoid a lot of problems and diagnosis during the initial phase of building and deploying a new cluster (and if it is possible), we would recommend the "easy button" approach as follows:
Enable the project with owner permissions to begin with
Deploy and configure the cluster(s), domain(s), and application(s) and verify they work correctly
Continue with the next section after the prerequisites to restrict access once the application stack is functioning properly
Otherwise, continue with the prerequisites.
Prerequisites
You should have an intermediate grasp of GCP IAM permissions, roles, and services in the GCP console or CLI. You can review the GCP IAM documentation before continuing.
The following services are required to be enabled. If you do not provide Release with sufficient privileges, we will not be able to automatically enable them in the target project. If the services are not enabled, then those functions will be disabled which could render deployments non-functional. Please verify these services are enabled via the console or CLI before you start:
artifactregistry.googleapis.com
compute.googleapis.com
container.googleapis.com
containeranalysis.googleapis.com
dns.googleapis.com
file.googleapis.com
iam.googleapis.com
sqladmin.googleapis.com
storage-api.googleapis.com
storage.googleapis.com
cloudresourcemanager.googleapis.com
secretmanager.googleapis.comReview the list of permissions and/or roles in the appendix of this document and gain an understanding of what resources/scopes may apply for these permissions.
Check with your Security, DevOps, and/or Compliance team(s) to whittle down or restrict permissions they may have any objections to. Be careful that any restrictions on the permissions may impact the functioning of our product.
Contact support to allow us to work with you to implement and test this as smoothly and seamlessly as possible.
Create a Role and Permissions
We would recommend creating a role with the full list of permissions in the appendix. However, there may be a list of predefined roles that you may find easier to implement that will cover most of the use cases Release needs to implement our functionality. Keep in mind that these pre-defined roles have two drawbacks: First, you cannot scope or filter resources for the predefined roles. Second, these predefined roles may have too many or too few permissions compared to the complete list of permissions required. On the other hand, it may be more convenient to start with these permissions. Follows is a list of predefined roles to start. You can enhance the permissions with ones pulled from the full list at the end.
Add Specific Permissions with Resource Filters
You will need to also add more permissions not covered by any pre-defined roles (or permissions that are not granular enough for your purposes). As an example, you may want to remove the DNS Admin role and instead filter reads and writes to a specific zone that you specify. See the examples here. You can also specify prefixes and complex queries for resources as shown in this example.
Appendix
Below is the entire list of permissions that Release requires for full functioning of the product. Some functions may not be necessary after setup and installation (but may be needed later for upgrades, etc.). Some permissions can be restricted to certain scopes or prefixes. But this list is the complete list of all permissions we feel are needed for full functionality. You can edit and restrict them as needed.
Last updated
Was this helpful?