通过在堡垒虚拟机上运行的 cloud-sql-proxy 连接到 CloudSQL

Question

我正在开发更安全的 GCP 项目设置迭代，其中有堡垒主机，并且 cloudsql 实例没有公共 IP。

在当前设置中，

cloud-sql-proxy

在本地用于访问 CloudSQL 实例。但在新的迭代中，我在堡垒虚拟机上开始了 terraform

cloud-sql-proxy

；

module "bastion-host" {
  source  = "terraform-google-modules/bastion-host/google"
  version = "6.0.0"

  project = var.project
  zone    = var.zone
  network = var.network
  subnet  = var.subnet
  members = var.members
  
  additional_ports = [
    "22",
    "3306",
  ]

  startup_script = <<EOT
    #!/bin/bash
    sudo apt-get update
    $(gcloud info --format="value(basic.python_location)") -m pip install numpy
    URL="https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.6.1"
    curl "$URL/cloud-sql-proxy.linux.amd64" -o cloud-sql-proxy
    chmod +x cloud-sql-proxy
    ./cloud-sql-proxy --private-ip ${var.project}:${var.db_instance_region}:${var.db_instance_name}
  EOT
  
}

resource "google_project_iam_member" "bastion" {
  for_each = toset(["roles/editor"])
  project  = var.project
  role     = each.value
  member   = "serviceAccount:${module.bastion-host.service_account}"
}

防火墙配置为允许 IAP IP 范围 (35.235.240.0/20) 的端口 22 和 3306。我已验证

cloud-sql-proxy

正在 3306 上运行，并在另一个端口上运行另一个实例并将其连接到数据库实例。

我可以从我的计算机打开到堡垒虚拟机的 SSH 隧道，但我无法将端口 3306 绑定到我的计算机以便通过该计算机访问数据库。我发现了一些关于这个一般主题的文章，但没有任何内容将运行

cloud-sql-proxy

本身的堡垒主机结合起来供人们路由流量。

我想做的是使用 IAP 将本地端口绑定到运行

cloud-sql-proxy

的堡垒虚拟机上的 3306，但我得到以下信息；

❯ gcloud compute start-iap-tunnel bastion-vm 3306 --local-host-port=localhost:3310 --zone=europe-west2-a --project=my-project

Testing if tunnel connection works.
ERROR: (gcloud.compute.start-iap-tunnel) While checking if a connection can be made: Error while connecting [4003: 'failed to connect to backend']. (Failed to connect to port 3306)

但是，我可以通过 SSH 连接到虚拟机并手动运行

cloud-sql-proxy

；

❯ gcloud compute ssh --zone europe-west2-a bastion-vm --tunnel-through-iap --project my-project

Linux bastion-vm 5.10.0-28-cloud-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Apr  9 09:45:12 2024 from 35.225.242.4
mwalker@bastion-vm:~$ cloud-sql-proxy --private-ip my-project:europe-west2:my-project-8-b7d9f5df
2024/04/09 12:36:07 Authorizing with Application Default Credentials
2024/04/09 12:36:07 [my-project:europe-west2:my-project-8-b7d9f5df] Listening on 127.0.0.1:3307
2024/04/09 12:36:07 The proxy has started successfully and is ready for new connections!

我还在虚拟机上运行了tinyproxy，我可以看到 kubernetes，尽管这是将所有内容都放在私有 IP 后面的难题的另一部分。

❯ gcloud compute ssh bastion-vm \
    --tunnel-through-iap \
    --project=alldam-production \
    --zone=europe-west2-a \
    --ssh-flag="-4 -L8888:localhost:8888 -N -q -f"

❯ export HTTPS_PROXY=localhost:8888
kubectl get ns
NAME              STATUS   AGE
default           Active   13d
kube-node-lease   Active   13d
kube-public       Active   13d
kube-system       Active   13d

Answer 1

事实证明这是一个错过简单/显而易见的经典案例。

启动脚本正在使用默认参数启动

cloud-sql-proxy

；

./cloud-sql-proxy --private-ip ${var.project}:${var.db_instance_region}:${var.db_instance_name}

这意味着它正在监听

localhost:3306

。

更新它以绑定到所有网络接口意味着我可以从本地计算机连接到它。

./cloud-sql-proxy --private-ip --address 0.0.0.0 --port 3306 ${var.project}:${var.db_instance_region}:${var.db_instance_name}

并添加端口以使其明确。