Ian Meikle – Senior Google Cloud Platform Engineer, Netpremacy
Google Cloud resources are easy to use and readily available, but to protect confidential data and limit costs, you should regulate who can access them. Google recommends applying the ‘Principle of Least Privilege’ – only grant the minimum permissions required for a particular account on a particular resource and no more. Within GCP this is controlled using Identity and Access Management (IAM). More specifically, by the setting and application of IAM Policy.
As a Senior GCP Engineer at Netpremacy, I regularly advise our customers on how to get more from their existing GCP setup by following Google best practices and applying what we’ve learnt first-hand over the years. Here I’ll explain how IAM works, how you can use IAM Policies effectively, and the best practices to follow. This blog is for anyone starting with GCP who wants to ensure they are granting the right permissions to their staff. Alternatively, if you already have existing GCP infrastructure, this article will guide you through making it more secure.
Identity and Access Management
Resources and Permissions
IAM is concerned with identity and access. It defines who can do what within your GCP setup. The ‘who’ can relate to a real person through a Google Account or a Google Group. However, permissions may also be granted to Service Accounts associated with apps or other compute resources. This is often done to allow automation. The ‘what’ is a resource in GCP. This can be one of many things, such as a GCE VM or a BigQuery DataSet. Every resource has a defined set of permissions that allow creation, administration, deletion or passive access. These permissions are then grouped into Roles, and a Role is assigned to an identity through an IAM Policy. Policies are then applied to resources within a project.
GCP infrastructure is organised as a hierarchy (see image below). At the top sits the Organisation. Below that there are (optional) Folders that are used to group Projects. Resources are collected within a Project. Permissions are inherited as you move downwards so that an identity with privileged access at the Organisation level will have the same access to all resources within the hierarchy. Privileged access granted to a Folder will similarly filter downwards to the folders and projects that it contains.
Permissions are closely related to API calls within GCP. As there are thousands of calls that can be made on nearly 200 different GCP services, permissions are grouped into Roles.
There are three types of Roles:
- Basic Roles These are Legacy roles that grant you Owner, Editor or Viewer control over a resource. Basic Roles are quite broad and should be used sparingly.
- Predefined Roles These are the most common type of IAM role and are usually associated with a specific service. For example, the roles/bigquery.dataViewer role grants 15 different permissions on a Dataset, Table or View within BigQuery that allow read-only access. Above this, there is the roles/bigquery.dataEditor, which includes permissions to create, update and delete Tables. Moving even higher is the roles/bigquery.dataOwner, which can create, update and delete Datasets.
- Custom Roles If there are no Predefined Roles that match your needs then new, Custom Roles can be created. These can be useful if you have specific compliance needs, for example. Be aware that GCP Service updates may change the set of permissions required for resource operations. Whilst Predefined Roles will be reconfigured automatically to match any change, the management of Custom Roles is your responsibility.
Assign roles to Google Groups, not users. Whilst it is easy to grant an IAM role to an individual user, this is not something we recommend. Consider what happens when someone leaves the company or transfers to another business unit. If their user identity is tied to a resource through an IAM policy then that resource can be left orphaned, with potentially harmful effects. Google’s recommendation (that we would endorse) is to assign roles to Google Groups and then manage group membership via the Workspace Admin Console. This makes the transfer of ownership much easier and dissociates service operations from user management.
Align permissions to job responsibilities. Projects are the ‘base’ unit within the GCP hierarchy. IAM Policies should be developed so that projects sit entirely within the remit of a team or business unit. In this way, permissions are aligned with job responsibilities. Cross-project working can be permitted through VPC networking, though that is not discussed here.
Use IAM Recommender to stay on top of resource access management. Access requirements change over time, so permission management is an ongoing process. Google has provided an IAM Recommender service that monitors how a resource is being used over time and suggests how to enforce the Principle of Least Privilege. Recommendations are based on recent service access and a Machine Learning analysis of how the role may need to access the service in the future. The Recommender can be used interactively as part of an IAM review, or automated. Whilst every effort is made to prevent unexpected service disruptions, automation carries the expected caveats.
Resource access has to be managed, and IAM provides the tools and processes you need to do just that. For optimum security and to enforce best practices, you should protect your GCP environment against accidental modification by users with elevated access permissions. A way to safeguard against this is to apply the principle of least privilege so that only the appropriate group of people make changes.
Google Groups helps you to create a clear distinction between user management and service operations. That means resource management happens in the right place without blurring the distinction between people and services.
Following the principle of least privilege is an ongoing process. Use IAM Recommender to help you stay on top of access rights and update permissions when needed.
For advice on using Cloud IAM or to book a GCP Health Check, contact us on firstname.lastname@example.org