Background

Organizing a User Access Review for SOC2, ISO, or SOX purposes can be a tedious process involving days of data gathering and formatting. One of the worst offenders of this is Google Cloud Platform, which doesn’t offer any easy way to export IAM principals, roles, and security insights from their admin panels.

Lumos can help you put together a GCP review in a matter of minutes with our Google Cloud integration. This article outlines Google Cloud’s IAM structure, which data Lumos pulls in from GCP and how that’s represented in Lumos, as well as some “gotchas” to be aware of when syncing this data into Lumos.

Google Cloud’s IAM Model

Google Cloud’s Resource Hierarchy

Google Cloud allows users to hierarchically organize their projects and resources. This means that you can organize your projects into folders and sub-folders, which can include more fundamental objects like projects and resources. One way to think about this is similar to how you can create folders within folders in Google Drive. See here for a detailed overview from Google Cloud on exactly how this works.

There are 4 important concepts to be aware of in a GCP environment:

• Organization: This is a top-level container for all your projects. These are named based on your Google Workspace domain — for example, at Lumos we use: lumos.com

• Folders: These are optionally used to organize projects within your organization. For example, you might have a folder for each department or team, and include those teams’ projects within their respective folders.

• Projects: A project is similar to what you would describe in engineering as a “project”. It’s a way to group together a set of resources, such as compute instances and storage buckets. In Google Cloud, you can only create resources as part of a project.

• Resources: These are the building blocks that you use to create and run applications and services in the cloud. Examples of resources in GCP include virtual machines, storage buckets, and databases.

  

An example GCP environment, organized using an organization, folders, sub-folders, projects, and resources. Credit: https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy

IAM Policies, Roles, and Permissions

Access to projects and resources in GCP is controlled through a combination of permissions, roles, and policies.

• Permissions: These grant a principal (e.g. a user) the ability to perform an action (e.g. “list”) through a service (e.g. “compute”) on a resource (e.g. “addresses”). These follow the structure of service.resource.verb. So putting it altogether, a permission might look like compute.addresses.list

• Roles: These are named sets of permissions. Permissions cannot be directly assigned to principals/users; instead they are assigned through roles. GCP has a set of predefined roles to handle most of your access management needs, but you can also define Custom Roles and select which permissions should be applied.

  An example of a role is Folder Admin, which has the following permissions:

  Referenced from: https://cloud.google.com/iam/docs/understanding-roles

  

• Policies: These are a way to bind roles to a set of principals, such as users, groups, or service accounts. A policy can be set on an organization, folder, project, or resource. Here is an example policy from Google’s official documentation:

  Referenced from: https://cloud.google.com/iam/docs/policies

  

  In this policy, we are assigning the role “Owner” to the user “jie@example.com”. This policy can be attached to any project, folder, or organization. More complex policies might assign access to groups, service accounts, or include conditions on which the policy is applied.

IAM Policy Inheritance

IAM policies in Google Cloud can be set at the organization, folder, project, or resource level. In contrast to other IAM models (such as AWS), policies set in Google Cloud cascade down the resource hierarchy.

This means that if you set a policy on the organization, it applies to every folder and project in that organization. Similarly, if you set a policy on a folder, it applies to every project in that folder.

Google Cloud Data in Lumos

Projects as “Apps”

In Lumos, we want to make it easy for you to automatically pull the data you’re going to review in the format that you want to review it in. We see Google Cloud access reviews most commonly happen at the project-level, so when you connect the Google Cloud integration to Lumos, we will automatically pull in all of your projects as “Apps” in Lumos.

This means when you’re conducting an Access Review, you can simply select the set of projects that you want to review as “apps”, automatically pull in all the assigned users from GCP, and delegate the user review to the appropriate owners in your organization.

In order to find a project from your Google Cloud environment in Lumos, you can go to the “All Apps” page, select the filter icon on the “Source” column, and filter by “Google Cloud”. You can then use the search bar to look for a specific project.

Groups, Service Accounts, and Domain-Level Access as “Accounts”

In Google Cloud, you can assign roles to a number of different principals. Some of the most notable are:

• Google Groups: Instead of assigning a role directly to an end user, you can assign it to users who are members of a particular user group, such as engineering@yourdomain.com. This way new users automatically get access to these projects.

• Service Accounts: Google has a principal known as a “service account”, which is distinct from normal users. You can assign roles to these accounts just like a user. See here for more details on Google Service Accounts.

• Members of your Domain: similar to how you can grant access to users via a Google Group, you can also grant access to any user in your organization/domain in a policy. This means any Google user with @yourdomain.com in their email can access the project.

To help you match the data you’re seeing in Lumos 1:1 with the data you see in GCP, we pull in all of these assignments as “Accounts”. So, let’s say you had a project called test-project that has 3 policy assignments:

• The user steve@yourdomain.com has the “Compute Admin” role on the project.

• The group sales-engineering@yourdomain.com has the “Compute Read-Only” role on the project.

• The service account mysa@yourdomain.iam.gserviceaccount.com has the “Compute Admin” role on the project.

You would see 3 accounts in Lumos associated with the project:

Here is an example of how a similar example would look in Lumos:

Lumos vs GCP IAM: Why you see more data in Lumos

If you’re familiar with the Google Cloud IAM panel, you might be surprised to see additional data in Lumos that is not visible in your IAM panel.

The reason for this is that the GCP IAM panel selectively filters out certain users and roles from the UI. They do this because some permissions are not relevant to your individual project and don’t actually grant access to the project (e.g. “Billing Account Costs Manager”).

However, their filtering logic is not complete, and doesn’t actually guarantee that users cannot access or modify the project you are viewing. For example, the Folder Admin role in Google Cloud can be assigned at the organization level, and grants permissions related to a project, but it does not show up in GCP.

In order to protect your environment, Lumos pulls in all of the role bindings we have available so you can see exactly which roles may apply to the project you’re looking at. As a result, you may see roles that you don’t care about (e.g. billing roles), but you can always scope these out of your review.

Other Resources

• Google Cloud Platform Resource Hierarchy

• Google Cloud IAM Overview

• GCP Permissions Reference (note: this is hosted by a third party, not Google)

• Understanding Google Cloud IAM Concepts with Stick Figures

• Identity and Access Management in Google Cloud Platform (by Ermetic)