GCP IAM Best Practices: A guide to IAM on Google Cloud

As your organization grows in size and complexity, its roles, access requirements, and resource needs scale with it. As a result, access management becomes increasingly complex, difficult, and expensive to maintain. One of the best solutions developed to deal with these issues is Google Cloud Identity and Access Management (IAM).

IAM creates a set of security rules that provide a high degree of security while still enabling easy access for users and administrators.

Achieving these conflicting goals, however, takes more than just using a solution picked straight out of the box. Managing your organization’s security, compliance, and resources needs close adherence to Google Cloud Platform (GCP) IAM best practices and strict attention to detail in how they’re deployed.

In this article, we go through the best practices of IAM security and detail precisely how you can follow them to improve results within your organization.

Google Cloud Identity and Access Management Basics

Put simply, IAM systems manage roles, actions, and resources for an organization. The details of how these systems work and the ways they can be chained together can become complex and highly detailed, however. As an example, a role could define an individual user, a group of related users, or an automated system performing a recurring action.

The number of roles available to organizations are almost infinite. Each one should have its own set of permissions and resources for access and monitoring.

A GCP IAM system is initially setup with a handful of basic roles defined as owner, editor, and viewer. These initial roles provide broad access permissions levels and access to users. In practice, these should rarely be used beyond the initial setup stages in a real-world environment. Instead, a set of predefined roles created by Google will provide the fine-grained access controls often needed.

Finally, an organization will almost certainly use a set of custom roles created by administrators to grant users set groups of permissions and access restrictions. In many cases, these roles may inherit or define access at various levels of the organization so that they reflect the company hierarchy.

A role’s permissions grant it access and use of resources either internal or external to the organisation. These three building blocks of IAM systems can be built on in a surprising amount of interesting ways. Doing so with GCP IAM best practices in mind, however, is the only way to ensure safe, robust, and reliable security within your organization.

Best Practices with Google Cloud IAM Security

IAM has become an invaluable part of the modern security framework. Ensuring that GCP identity and access management tools and processes are following best working practices should be a high priority for security-conscious organizations.

1. Maintaining The Principle of Least Privilege

One of the most common and most critically important best practices is applying the principle of least privilege. IAM least privilege refers to an information security concept in which users are given the minimum levels of access or permissions without interfering with users’ daily workflows. This practice is fundamental in protecting privileged access to high-value data and assets.

Image Source

While organizations can implement role-based access control with Google Cloud, they can also leverage attribute-based access control to define the permissions necessary across different departments further. However, the end goal is regularly auditing usage and reducing unnecessary permissions. The principle of least privilege is also vital to limit administrative access so that single admins don’t have excessive permissions.

Google Cloud’s role recommendations can help teams identify the least privilege necessary for users to access necessary resources.

By strictly limiting super-user and administrator privileges, the least privilege enforcement helps to reduce the overall cyber attack surface. However, as a service scales – so does the number of IAM roles and inter-related privileges.

Policy Intelligence is a revolutionary AI and ML enforcer working on Google Cloud to leverage an organization’s data to optimize its own IAM policies.

Policy Intelligence is like a policy traffic policeman that seamlessly:

• Rolls out policy changes
• Maintains information on who has access to what

Simulates policy changes to ensure the right stakeholders have relevant access

Image Source

 Register Now

 

Reviewing and Removing Excess Permissions on Existing Service Accounts

As we’ve mentioned, IAM security ensures users have the right access privileges. Without this, everyday operations like bulk approvals for access requests and the lack of access review processes would lead to excessive access privileges.

Under the GCP IAM system, one doesn’t directly grant permissions. Instead, organizations grant roles that contain one or more permissions. These IAM roles are divided into basic, predefined, and custom roles.

The GCP IAM best practices warns users against using basic roles unless there is no alternative, as basic roles include thousands of permissions across all Google Cloud services.

If such an unmanaged service account were to remain neglected, it would present an attack surface vulnerable to compromise and exploitation. Thus, the solution is to go with Predefined or Custom roles. While predefined roles are created and maintained by Google, Custom roles are user-defined and allow you to bundle one or more supported permissions to meet your specific needs.

Image Source

We advise that organizations follow the practice of creating a dedicated custom service account for each instance and use another custom service account for each application, and grant required access. Although this may seem complicated to manage, it will be advantageous in the long run. Moreover, GCP’s IAM recommender alerts you to the permissions that are not used by the service account, and you can remove/modify them accordingly.

Introducing Google’s Policy Troubleshooter helps you investigate access issues. For instance, if a user has permission to access an asset but is unable to call an API, the Policy Troubleshooter will quickly pinpoint why a user doesn’t own a particular access.

To access the Policy Troubleshooter on your GCP console, head over to IAM & Admin > Policy Troubleshooter

Now, the tool prompts you to fill in three key parameters:

For more info on resource name nomenclature, check out the official documentation.

Once you have filled out the form, click on Check Access.

With reference to the annotations on the screenshot:

1. The top portion validates the evaluation info of the principal user.
2. The **IAM allow policy details** shows the access granted
3. Finally, **role bindings** reveal roles that contain the relevant permissions

1. a. Click on Role binding details to view more details

The result is a holistic and comprehensive background check on any user’s access privileges – thus helping system admins to easily analyze why access issues arise.

3. The Service Account Key

Unlike normal users, service accounts do not have passwords. Instead, service accounts use RSA key pairs for authentication: Since the private key allows you to authenticate as the service account, having access to the private key is similar to knowing a user’s password. This private key is called the service account key. The key pairs used by service accounts are divided into two categories: System-managed and User-managed.

System-managed key pairs are automatically rotated by Google and are used for signing for a maximum of two weeks. On the other hand, User-managed key pairs can be created and deleted by users. Users are responsible for rotating these keys periodically to ensure the security of their service accounts.

Image Source

However, service account keys can become a security risk if not managed carefully. Credential leakage, privilege escalation, and non-repudiation are some of the main threats related to service account keys. As mentioned in the google cloud documentation on service account keys, you can follow certain practices to avoid these threats:

1. Use alternatives to creating service account keys.
2. Use organization policy constraints to limit which projects can create service account keys.
3. Don’t leave service account keys in temporary locations.
4. Don’t pass service account keys between users.
5. Don’t submit service account keys to source code repositories.
6. Don’t embed service account keys in program binaries.
7. Use insights and metrics to identify unused service account keys.
8. Rotate service account keys to reduce security risk caused by leaked keys.
9. Use uploaded keys to let keys expire automatically.

4. Workload Identity

Some applications running on GKE (Google Kubernetes Engine) might need access to Google Cloud APIs. Workload Identity allows a Kubernetes service account in your GKE cluster – outside Google Cloud – to impersonate a service account by using credentials from an external identity provider.

The process of configuring Workload Identity works by using an IAM policy which binds the Kubernetes service account member name to an IAM service account (having the permissions your workloads need). Since Google manages the namespace service account credentials, the risk of accidental disclosure of credentials is much lower than service account keys.

Moreover, the credentials issued to the Workload Identity are only valid for a short time, thus, reducing the blast radius in the event of a malware attack.

DevOps and Least Privilege Policies

DevOps teams are made up of both development and operations staff working together with combined knowledge and experience in creating cloud services. Companies such as D3V specialize in the Google Cloud Platform and creating IAM solutions for clients at any scale.

When it comes to cloud infrastructure, cloud platforms, and cloud applications DevOps teams are extremely focused on security and compliance. Best practices must be followed to maintain secure deployment in a Google Cloud environment and ensure system roles are strictly separated and tightly controlled.

Maintaining this approach ensures that even the DevOps team responsible for continuous delivery has only the access they absolutely require to deploy and maintain the system and no more. For example, principles of least privilege dictate that even teams with the broadest administrator role don’t need access to manipulate code at its most granular level.

As a result, you can efficiently manage the security functions and properties in the delivered code to evade vulnerabilities from both internal and external threats.

Wrapping Up

Checking that these four best practices are followed is the number one thing you can do to ensure your GCP IAM solution is effectively deployed. Just checking that your solution follows closely to the principles of least privilege alone will make sure you’re on the right track. Combining that with regularly reviewing account permissions, using RSA tokens, and configuring workload identities will guarantee your system is reliably secured for any size of organization.

In addition to these steps, Google Cloud Platform also offers whitepaper guides and a checklist for security policies and best practices on Google Cloud to assist both small and large in maintaining their IAM security. The D3V Team also offers free strategic consultations if you or your organization needs further guidance!