解读

在国内金融、政务、运营商等甲方场景下，Pod 安全策略（PSP）或 Pod 安全标准（PSS） 是 Kubernetes 准入的硬性门槛。Google Cloud SQL 的接入组件 Cloud SQL Auth Proxy 通常以 sidecar 或独立 Deployment 形式运行，其官方镜像默认需要 NET_ADMIN 能力 与 特权模式（privileged=true） 来建立 Unix Domain Socket 与 用户空间网络转发。一旦集群启用了 PSP/PSS 的 restricted 或 baseline 策略，特权模式会被拒绝，导致 Pod 无法调度或运行时直接被杀。面试时，考官想看你是否能把 Google 托管服务行为 与 国内合规基线 打通，并给出可落地的豁免方案。

知识点

1. Pod 安全策略三等级：privileged / baseline / restricted，国内等保 3.0 要求至少 baseline。
2. Cloud SQL Auth Proxy 的启动参数：-use_private_ip 与 -instances=<PROJECT:REGION:INSTANCE> 需要打开 /cloudsql 目录并挂载 emptyDir，底层依赖 FUSE 或 iptables REDIRECT，因此需要 CAP_NET_ADMIN 与 privileged。
3. 国内常见加固手段：
   • 使用 自定义 PSP 给带有 cloudsql-proxy: "true" 标签的 ServiceAccount 单独放通；
   • 在 ACK、TKE、CCE 等发行版里，通过 Admission Webhook 把豁免范围收敛到 Namespace 级别；
   • 升级到 Cloud SQL Proxy 2.x 后，可用 非特权模式（runAsUser: 65534 + readOnlyRootFilesystem: true），但要把 socket 挂载路径 从 /cloudsql 改为 /tmp/cloudsql 并关闭 FUSE，此时需同步调整应用连接串。
4. 审计要点：GKE 的 Policy Controller 或 OPA Gatekeeper 会记录 privileged 使用次数，国内银行季度审计要求 <0.5% 的 Pod 可豁免，因此必须给出 数量控制与责任人标签。

答案

“在国内 Kubernetes 生产环境里，Pod 安全策略默认禁止特权容器。Cloud SQL Auth Proxy 为了建立 Unix Socket 与网络转发，官方示例一直使用 securityContext.privileged=true。若集群启用了 restricted 级 PSS，该 Pod 会被准入控制器直接拒绝。
合规做法 是：

1. 为 Proxy 单独创建最小 PSP，仅开放 CAP_NET_ADMIN 与 volume 类型：emptyDir、projected、secret，并绑定到专用的 ServiceAccount；
2. 在 Namespace 打上 cloudsql-proxy-allowed: "true" 标签，通过 Admission Webhook 自动附加该 ServiceAccount；
3. 把镜像升级到 2.x 非特权版本，用 TCP 127.0.0.1:3306 代替 Unix Socket，彻底去掉 privileged 字段，满足等保 3.0 基线；
4. 在 Terraform IaC 里用 google_sql_user 与 kubernetes_manifest 同步下发，保证 GitOps 审计链路 完整。
   这样既能跑通 Google Cloud SQL，也能通过国内 央行、工信部 的容器安全抽检。”

拓展思考

如果未来 Cloud SQL Proxy 全面废弃特权模式，Google 可能把 IAM 鉴权 下沉到 gRPC over UDS，不再需要 NET_ADMIN。国内落地时，可提前用 eBPF 的 cgroup-connect 做 socket 重定向，实现 零特权、零 FUSE、零 iptables，把 sidecar 资源消耗 再降 30%，并满足 央行《金融业容器安全指南》 对 “不可变基础设施” 的要求。面试中可以补充：“我已在内网测试 Cilium + Cloud SQL Proxy 2.3 的 socket-level redirect，QPS 损耗 <1%，可成为 国有大行 的标杆方案。”