Personally I feel like AWS has forever poisoned the well for me on those but I get the appeal.
Great, I read that document. Big, long wordy thing. Nothing about service accounts. I see this other one in there that looks promising. https://cloud.google.com/iam/docs/overview No dice, but I do see mention of service accounts in the nav bar. https://cloud.google.com/iam/docs/service-accounts Close, but ultimately not what I need, try two more. Now I'm 5 documents deep and I'm honestly wondering what I'm doing.
I finally piece together that I need to create a service account explicitly grant it a role download credentials export the credentials location
How hard would it be to write that in one place and call it something like "How to use service accounts (and why)"
But wait! It still doesn't work, gotta activate the Cloud Asset API (have you ever tried to use an AWS service and failed because the something something api wasn't active yet? No you haven't) Ever run into an api usage limit? That's a fun one. Imagine that api is the one you're using to report problems with your production cluster. Good luck getting that fixed in a reasonable period of time. I ended up just waiting 24 hours for it to reset. But I digress.
Ok, so I do all that. Only to figure out that's not quite what I need so now I'm chaining together some gcloud commands, filtering output, making tables, sorting in vi.
I wind up with a 192 line spreadsheet and a lot of manual work remaining to work through them all. Maybe this stuff is available in the Google Security Center, but I can't see it because it's helpfully hidden under the organization permissions not the project permissions. Great.
You know how you do this on AWS? This very important security thing that you should do quarterly if not more often? You click on trusted advisor, it shows you the unattached security groups you can safely delete, it advises the ones you should lock down. Done.
Don't get me wrong, Google network infrastructure is generations ahead of AWS. But it's all useless if you can't get it working right and GCP documentation is worse than nothing at all. So good luck getting things working right.
Also when things are just a bit more complicated the odds are good that even smart, capable people will screw something up (yes I found some problems during my audit today, no I don't think those problems would have been there if the client had deployed on AWS or Azure)
In conclusion think twice before choosing GCP
The most galling thing is GCP support. I'm on a team which pays for google support and it is by far the most lax, useless nonsense I've ever encountered. They are literally no help.
In my experience 1 and 3 are true for AWS as well. AWS has automated tools to detect things but to say that GCP does not have any such offering is not true. It may not be automated and that goes to the larger point of AWS being more mature.
https://cloud.google.com/vpc/docs/firewall-rules-logging https://cloud.google.com/network-telemetry
Developer experience and User education is where GCP needs a lot of catch up to do.
