jacks-reid.xyz

My Least Favorite GCP Role

Out of all the IAM roles that are predefined by Google Cloud, there’s one that sticks out the most to bother me. roles/viewer.

There’s obvious problems with the role:

  • The role is a member of the legacy basic roles, meaning Google Cloud has highlighted these roles are the opposite of best practice. Because of this association as a basic role, your CSPM is likely to throw alerts in your face about it.
  • The role has over 3300 permissions (currently)! Good luck trying to slice that list down into something more manageable during your quarterly IAM review. Even if you wanted to create a custom viewer role, note that custom roles in GCP have a limit on the number of permissions you can add to it.
  • The role title implies that it is fairly benign, leading many organizations to grant the roles/viewer role to users at the Google Cloud Organization level, where the permissions will then inherit down to the entirety of the GCP environment.
  • The role is continuously receiving new permissions as new APIs and services are added to Google Cloud. Your IAM bloat won’t be getting any smaller.

So what’s the big deal with having excess permissions for view access? Granting roles/viewer is a whole lot easier than trying to get granular permissions for random job titles.

My main complaint with roles/viewer is that the name is fairly misleading. A viewer entitlement implies that you can only read the environment, the challenge with a read permission is all the different things that you CAN read.

Let’s cut out all the ‘list’ and ‘get’ permissions from roles/viewer. There’s a lot here! But to be fair a decent chunk are synonyms for view or likewise reading activities.

gcloud iam roles describe `roles/viewer` | grep  -v -e 'get' -e 'list'
# over 350 different permissions!

Here are a few highlights from that permission list:

# both totally fair game for ‘read’ access, but these are the exact API methods that CSPM tools like to use to find misconfigurations in your environment. 
# I’m sure hackers would like to do the same. A reverse, bad-intentioned CSPM if you will :) 
- cloudasset.assets.searchAllIamPolicies
- cloudasset.assets.searchAllResources

# chronicle Forwarders can be used to ingest logs into a SIEM solution. 
# It includes an involved setup and deployment of agents (oftentimes on-premises) to ingest logs into the platform. 
# That doesn’t sound like a read-only permission.
- chronicle.forwarders.generate

# And THIS is the reason I wrote a blog!
- bigquery.jobs.create

bigQuery.jobs.create gives you access to query a BigQuery dataset. Yes, that service where your organization probably has a lot of sensitive data sitting. Not only can roles/viewer query that dataset, but because the role is often granted at the Organization level, via inheritance users with the roles/viewer role can now query any BigQuery dataset in your environment. Are the folks you are giving roles/viewer to in your environment similarly trusted to run queries against BigQuery? That’s probably a stretch of the original intention.

At the end of the day, Google Cloud doesn’t recommend using roles/viewer. I agree with that assessment, but anyone operating in GCP knows that folks will ask for roles/viewer all the time. The role is similarly (and correctly) gaining new permissions all the time with the launch of new GCP services. It’s BigQuery today, but what happens when the next service includes a permission akin to bigquery.jobs.create? Are GCP security engineers going to pick up on that one fast enough?

I would love for GCP to create a ‘sanitized’ version of roles/viewer and recommend to customers to migrate to the newer, safer version.

Acknowledgements

I drafted this blog post and then forgot about it. Earlier this week I saw a Medium post on the same topic in the Google Cloud community. That post inspired me to finish up my own version of the analysis. I recommend reading both posts as different topics are tackled in each one.