Hacker News Reader

Comment by leblancfg | Hacker News Reader

You had to scroll all the way down the article, but:

>Therefore, if a customer ever enabled Private IP access to their instance, they could be targeted by an attacker-controlled Cloud SQL instance. This could go wrong very quickly if the customer solely relied on the instance being isolated from the external world, and didn’t protect it with a proper password.

Anyone care to expand on that? Would that be common practice?

View on HN

They're making a reasonable assumption for a bare-metal network, but their conclusion doesn't hold for Google Cloud (and likely Azure/AWS). A customer's Cloud SQL instances do not live in the same VPC as another customer's, and in Google Cloud, VPCs are fully isolated -- 10.0.0.0/8 in VPC A is a distinct network from 10.0.0.0/8 in VPC B, and the two cannot communicate unless there is a Cloud VPN, VPC peering, or a multi-NIC instance acting as a bridge between the two. The broad firewall rule is harmless; I must admit I'm not even sure why the iptables rules are there at all. Probably something about security and onions.

Source: I work in GCP support.

If you work in GCP support, have you ever looked at the Cloud Spanner project(s) in Pantheon? There are thousands and thousands of Cloud SQL VMs sitting in one project, so it's absolutely plausible that there might be some traversal possibilities.

Hopefully not much in prod, but I'm sure there are a lot of staging and dev databases which aren't protected by meaningful credentials.

I dont think this would really happen. You aren't likely running directly on bare metal, you're probably still encapsulated within a VM. The host system will also have it's own set of layer2, and layer3 firewall rules in additional to ARP locks, etc.

It depends on what else is on the same VPC network. Ip address spaces are virtual here.

In practice, this network may only contain instances of limited use cases.

Reply on news.ycombinator.com