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

[dolfandringa]

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?

[dionv]

Hello @dolfandringa ,

To answer your inquiries:

1. When a default service account is created, it is automatically granted the Editor role (roles/editor) on your project. This role includes a very large number of permissions. We strongly recommend that you either disable the automatic role grant by adding a constraint to your organization policy, or revoke the Editor role manually. If you disable or revoke the role grant, you must decide which roles to grant to the default service accounts, then grant these roles yourself.
2. As per guillaume blaquiere, it is best to switch to using Uniform IAM policy, with a downside you need to need to set it every time that you create a new file because new create files aren't ACL.
3. What I can suggest for this question to refer you to the best practices for managing your service accounts.