Google Cloud IAM is Google Cloud’s core component which keeps you secure. By adopting the methodology of “the least privilege principle,” you can work to have your infrastructure accessible only to those who need it. The idea of keeping your IAM permissions correct may seem daunting as your organization grows in size, so here’s a checklist of what you should think about before changing permissions. This can also benefit you, as you apply your access control continuously.
1. Who? (The “Identity”)
The first step in granting IAM permissions is to narrow down the person or thing that will access resources. That can be one of several possibilities, including:
- Google account (generally used by a person)
- A service account (a script/tool usually used)
- A Group of Google
- A Domain G Suite
Our greatest recommendation for this step is to limit that to as few identities as possible. While allowances may need to be assigned to a larger group, starting with a smaller subset and adding permissions as needed over time is much safer.
2. What Access? (The “Role”)
Google Cloud permissions often correspond directly to a particular method of the Google Cloud REST API. Those permissions are called based on the GCP operation, the particular resource, and the authorized verb. For example, to issue a start command to instances in Google Compute Engine, ParkMyCloud requires permission named “compute.instances.start.”
These permissions are not directly granted but are instead included in a role that is assigned to the identity you have chosen. There are three types of roles:
- Primitive Roles – These basic roles (Owner, Author, and Viewer) require a large range of permissions for all GCP services, and should be avoided in favour of more common needs-based roles.
- Predefined Roles – Google provides many roles describing a collection of permissions for a particular service, such as “roles/cloud SQL.client” (which includes the “cloud SQL.instances.connect” and “cloud SQL.instances.get” permissions). Some roles are wide and some are small.
- Custom Roles – If there is no predefined role that fits what you need, you can build a custom role that includes a list of different permissions.
3. Which Item? (The “Resource”)
Using a Cloud IAM policy, you will need to assign those permissions to a resource once you have decided on the identity and the permissions. A resource can be very granular or very wide, with things like:
- GCP Projects
- Single Compute Engine instances
- Cloud Storage buckets
Each predefined role as a resource that can be set to the “lowest” level. The “App Engine Admin” role, for example, has to be set at the project level, but the “Compute Load Balancer Admin” can be set at the level of the compute instance. You can always go higher than the minimum in the resource hierarchy.
As with the Identity problem, our advice is to restrict this to as few tools as possible. In practice, this could mean making a separate project to group resources together so that an identity can be assigned a role at the project level. Alternatively, when possible, you can select just a few resources within a project, or even an individual resource.
