Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Why are gcp IAM permissions so open by default and how should I restrict them?

I have a GCP cloud setup by someone else through the GCP console with the default permissions. There are some buckets, compute engine vms and cloud run services in there. I am moving it to terraform deployments, and want to tighten down the permissions. I see that by default, there are a number of default service accounts that have role bindings at the project level, which means they have those permissions for everything within the project. For instance the Compute Engine Service Agent role has

storage.objects.create
storage.objects.get
storage.objects.list
storage.objects.update 

and the Cloud Run Service Agent role has

storage.managedFolders.get
storage.managedFolders.list
storage.objects.get
storage.objects.list 

If I understand the permission system correctly, this seems to contradict the least privilege principle that google seems to advocate.

So I have the following questions about it:

  1. Is my understanding correct that the default service accounts have project level access to a lot of resources in gcp by default? The two I highlight means that they would have read or even write access to all GPC buckets by default. And if I understand correctly, the default service account for Compute  Engine vms means any vm has by default permission to read and write to any object in any gcp bucket.
  2. If my understanding is correct in the previous point, how do I follow the least privilege principle with GCS buckets, restricting access to a bucket to only specific roles/principals explicitly? It seems like the project level default permissions still grant access to the buckets, even if I set a policy at the bucket level that only grants access to specific roles.
  3. Is it the intention of google that to improve security and limit access to  resources and follow the least privilege principle, I have to replace all the default service accounts, and replace the default roles by more restrictive roles manually? That seems like a large amount of work, and still it doesn't prevent an admin from using one of the default ones later on and still unintentionally provide access to resources that they shouldn't have access to.
  4. Is there a way at the resource level to specify role bindings that are authorative, and override anything given at the project level?

 

 

2 1 1,937