-1: consider if you have complex vendor software on a GCE VM inside a larger GCP project... now a vulnerability in that vendor software means the whole GCP project is exposed. Vendor fixes are notoriously slow, so in practice you have to isolate vendor software to separate GCP projects.
Real example: I have a client with precisely this situation, and elsewhere in the GCP project is PII consumer data requiring public disclosure if exposed.
Luckily, GCE limits Cloud API access available to an instance to nothing by default. Meaning that access to BigQuery, Storage, SQL, User manage, etc is not allowed on that VM, even with root access to the VM, unless configured by the administrator.
This at least mitigates the the impact of this exploit to a degree. If a web server has access only to Cloud SQL, an attacker cannot use access to that VM to go digging around in Cloud Storage buckets unless GCS access is granted explicitly to the VM.
From there, IAM security applies. So even if the VM has Cloud API access to, say Big Query, the limitations of that Service Account then applies to any data that is accessed.
Well, so GCP is pretty big on serverless architecture. It is completely possible that there is no GCE instance at all which has Cloud API access to a particular service.
A company might be making heavy use of BigQuery in their project, but have a data processing pipeline that uses tools like Cloud Functions, Scheduled Queries, and BQ Transfer Service to push sanitized data into a Cloud SQL instance for the front end to use.
So no GCE instance will need Cloud API access to BigQuery, so no matter what level of access is obtained by an intruder on any VM, they will never be able to access BigQuery.
I completely agree and didn't mean to suggest it wasn't a serious vulnerability: as I understand it this attack means that if any VM in the subnet is compromised that can be leveraged in to an attack on any VM in the subnet so your attack surface has suddenly gotten a lot bigger and your isolation between VMs substantially poorer.
Most of my GCP clients shove PII into a GCP Service, like BQ. It's not put on a "server" per se, so firewall rules don't really apply here. The appropriate thing to assert is that necessary IAM permissions should be granted explicitly.
This is usually the case. As most of my clients use isolated GCP projects for housing PII data. This forces IAM permissions to be granted service accounts, which, hopefully, means that administrators are cognizant of the levels of access that they are granting to service accounts.
Not a guarantee, mind you, but hopefully some redflags would be raised if a someone requested PII-level access for a Service Account associated with a public facing web server.
IIUC this is insufficient (!) - even with a firewall between them, a VM now vulnerable to attack from another VM on the subnet (in the same GCP project).
I think the real learning here is not to colocate different things in a single GCP project. AFAIK projects don't cost anything so why not create one per service?
The way you're wording this suggests that this was a sensible design prior to this vulnerability, but in fact all sorts of tools, config, etc work within a project but not across projects, including IAM. Yes obviously anything can be duplicated but it's a big pain.
Probably easier to create separate subnets for VMs that don't trust each other ?
IAM works across projects easily. The "Organization" concept it Google Cloud is used to collect projects, and manage permissions of groups (or subfolders) of projects very easily.
Real example: I have a client with precisely this situation, and elsewhere in the GCP project is PII consumer data requiring public disclosure if exposed.