Okay, let's get this off my chest. I've been knee-deep in both AWS and GCP for the last few years, mostly trying to make them play nice with our CRM data pipelines.
And I keep hitting the same wall: trying to build a secure, least-privilege setup in GCP feels like trying to sculpt with a sledgehammer compared to AWS IAM.
The granularity just isn't there. In AWS, you can write a policy that allows `s3:GetObject` but only for objects with a specific tag prefix, from a specific IP range, during business hours. In GCP? Good luck. Their predefined roles are these massive, monolithic things. Need someone to manage Cloud SQL instances? Give 'em `roles/cloudsql.admin` and watch them get a bunch of other permissions (like network management) you never intended.
Even custom roles are a half-measure.
* You can only use permissions from the *massive* predefined roles, so you're just carving down from their overly-broad starting points.
* No resource-level conditions that are anywhere near as expressive as AWS IAM policy conditions. Want to restrict Pub/Sub topic creation to a specific region? Not a built-in condition type.
* The whole "v1", "v2", "beta" permission mess means you're constantly guessing which one actually works.
It feels like GCP's answer to everything is just: "Use a service account and hope for the best." Am I missing something? Or is the consensus that you just accept the blast radius is wider in GCP and move on?
been there, migrated that
I'm just starting to set up our GCP permissions for marketing analytics, and you've hit on my biggest headache. So you can't set conditions based on resource tags or time windows at all? That seems like a huge gap for securing customer data exports.
Is there really no workaround, like using VPC Service Controls instead? Or do you just have to accept the broader permissions?
It's not just you. That v1, v2, beta permission fragmentation is a massive operational risk that nobody talks about enough.
You'll build a custom role using the "v1" permissions listed in the docs, only to find the actual API call requires the "v2" version of that permission, which isn't in the predefined role so you can't add it to your custom one. Now you're stuck granting a broader predefined role just to get that one "v2" action.
The workaround? You end up managing service accounts as proxies for specific tasks, because you can't get the fine-grained control directly. It adds complexity and more failure points to your pipeline.
Show me the query.
Oh man, the predefined role thing is exactly what I'm fighting with right now. I tried to set up a service account just to write query results to a specific BigQuery dataset, and I thought `roles/bigquery.dataEditor` would be perfect. Turns out it also lets you delete tables and datasets across the whole project? That seems wild.
So even the "editor" roles are still way too powerful for a single task. Is the general advice just to always build custom roles from scratch, even though it's a pain?
null