解读

面试官想知道你是否真正“踩过坑”：在中国区（vpc-sc 已商用）的落地场景里，“加入”≠“生效”。很多候选人只回答“看控制台打勾”或“跑 gcloud describe”，结果现场追问“为什么仍然能跨项目读数据？”就哑口无言。
因此，回答必须覆盖三条主线：

1. 配置层：Cloud SQL 实例的 VPC 对等连接 与 Service Perimeter 的 双向绑定 是否成功；
2. 策略层：Perimeter 的 Ingress/Egress Rule 是否放行 Google APIs 服务账号 与 内部 VPC 源；
3. 流量层：真实数据路径是否被 VPC-SC 的强制校验点 拦截或放行。

只有同时通过“控制台状态 + gcloud 签名 + 实际访问 + 审计日志”四重验证，才能给出“已正确加入”的严谨结论。

知识点

• VPC Service Controls 在中国区的 Service Perimeter 模型
• Cloud SQL 私有 IP 的 VPC 对等连接（servicenetworking.googleapis.com）与 PSC 转发规则 差异
• Google-managed service account（service-PROJECT@service-networking.iam.gserviceaccount.com）在 Ingress Rule 中的 身份豁免机制
• gcloud access-context-manager 命令族与 restricted.googleapis.com 的 CNAME 解析
• Cloud Audit Logs 中 “VPC_SERVICE_CONTROLS” 的 DENIED 与 ALLOWED 事件
• Cloud SQL Auth Proxy 在 Perimeter 内 与 外 的 行为差异（是否触发 TLS 封包重定向）

答案

步骤化验证，每一步给出可落地的 gcloud 命令 与 预期回显，方便在面试白板直接写：

1. 查看实例级状态
   gcloud sql instances describe <INSTANCE_ID> --project=<PROJECT_ID> --format="value(settings.ipConfiguration.privateNetwork)"
   回显应为 projects/HOST_PROJECT/global/networks/VPC_NAME，确认已使用 私有 IP 且网络属于 Perimeter 关联的 VPC。

2. 确认 Perimeter 成员
   gcloud access-context-manager perimeters describe <PERIMETER_NAME> --policy=<POLICY_ID> --format="json" | jq '.status.resources[]'
   应出现 “//cloudsql.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID”；若未出现，说明 未加入。

3. 校验 VPC 对等连接已受控
   gcloud compute networks peerings list --project=<HOST_PROJECT> --network=<VPC_NAME> --format="table(name,stackType,state)"
   找到 servicenetworking-googleapis-com，状态为 ACTIVE，且 stackType=IPV4_ONLY（或 IPV4_IPV6），表明 Google 侧 已把该 VPC 对等连接 纳入 Perimeter 管控。

4. 验证 DNS 解析路径落入受限 VIP
   在 Perimeter 内 GCE 实例 上：
   nslookup restricted.googleapis.com
   必须返回 199.36.153.4/30 网段；若仍解析到 216.58.x.x，说明 DNS 策略 未指向 restricted VIP，VPC-SC 不会生效。

5. 执行跨项目访问测试
   在 同一 Perimeter 的 另一个项目 VM 内：
   gcloud sql connect <INSTANCE_ID> --user=test --quiet
   能登录即 Ingress Rule 正确；
   再在 Perimeter 外 VM（无豁免）执行同一命令，应收到 “ERROR 403 (VPC_SERVICE_CONTROLS)”；
   若外网仍能登录，说明 Egress Rule 放行了 0.0.0.0/0，不合规。

6. 审计日志二次确认
   在 Cloud Logging 过滤：
   protoPayload.methodName="cloudsql.instances.connect" AND
   jsonPayload.vpc_service_controls_status="DENIED"
   若 Perimeter 外 访问产生 DENIED 事件，而 Perimeter 内 为 ALLOWED，则 闭环验证 完成。

拓展思考

• 双网卡场景：若 GKE Pod 通过 非主网卡 访问 Cloud SQL 私有 IP，需确保 别名 IP 范围 也加入 Perimeter 的 VPC 范围，否则 VPC-SC 会旁路。
• PSC 后端服务：未来 Private Service Connect 发布 Cloud SQL 后端 后，Perimeter 需额外保护 PSC 转发规则 的 子网，否则 跨租户访问 可绕过 VPC 对等 限制。
• Terraform 流水线：在 CI/CD 中，用 google_access_context_manager_service_perimeter_resource 资源 串行化 添加 Cloud SQL 后，必须 sleep 90s 再跑 步骤 5，因为 中国区 的 ** propagation delay** 常导致 假阳性 PASS。