GCP账号购买 GCP谷歌云内网安全防护
你有没有试过半夜三点被PagerDuty叫醒，只因为某台Compute Engine实例突然开始疯狂外连192.168.3.11——而它本该只跟同VPC里的数据库说话？
别急着查日志，先深呼吸，然后默默打开GCP Console，点开那个你三年没碰过的默认网络防火墙规则……呵，果然，default-allow-internal还亮着绿灯，default-allow-ssh和default-allow-rdp像两个穿睡衣站岗的保安，对所有来源IP微笑放行。
GCP账号购买 欢迎来到GCP内网安全防护的现实世界——它不像AWS Security Groups那样“删错一条规则就断网三小时”的战战兢兢，也不像Azure NSG那样层层嵌套到让人怀疑人生。GCP的内网防护，是优雅与疏忽并存的双人探戈：一边是VPC Flow Logs、Identity-Aware Proxy、Private Google Access这些高阶选手列队待命；另一边，是你刚用gcloud compute instances create随手起的实例，默认开着22端口，且没配任何网络标签（network tag），结果防火墙规则里那条“仅限web-server标签”的规则，根本没拦住它。
第一课：别信‘默认安全’，信自己删掉的规则
GCP的VPC网络天生隔离，但‘隔离’不等于‘安全’。同一VPC里，A实例能直接ping通B实例，不是因为信任，而是因为没人说‘不’。GCP防火墙规则是状态化、无状态双向生效的——你放行了入站TCP 80，出站响应包自动放行；但如果你只写了入站SSH，出站响应却可能被另一条更严格的规则拦截（别笑，真有人这么配过）。
实操建议：新建项目后第一件事，不是部署应用，而是执行这三行命令：
gcloud compute firewall-rules delete default-allow-ssh --quiet
gcloud compute firewall-rules delete default-allow-rdp --quiet
gcloud compute firewall-rules delete default-allow-icmp --quiet删完别慌。马上补三条精准规则：
→ allow-ssh-from-jump-host（源IP限定跳板机）
→ allow-health-checks（目标标签lb-health-check，协议tcp:8080）
→ allow-app-internal（源/目标均为app-tier标签，端口3000,5432）
第二课：私有Google访问（PGA）不是‘高级功能’，是基础刚需
你以为关掉公网IP就万事大吉？错。你的Cloud SQL实例没公网IP，但它仍会通过互联网访问metadata.google.internal获取服务账号token；你的Kubernetes Pod默认用https://storage.googleapis.com拉镜像——这些流量，全走NAT网关或默认出口，暴露在公共互联网上。
PGA一开，所有对Google APIs（Cloud Storage、Pub/Sub、Logging等）的调用，自动走Google骨干网内网通道，加密、低延迟、不计费、不经过公网——而且，它还能防DNS劫持。某次我们发现一个Pod总在凌晨2点尝试解析storage.googleapis.com到一个境外IP，查了一周才发现是本地DNS缓存污染。PGA启用后，这个域名直接解析为169.254.169.254（内部VIP），绕过所有外部DNS。
开启方式？两步：1）VPC级别勾选“Enable Private Google Access”；2）确保子网路由表里有169.254.169.254/32指向default-internet-gateway（GCP自动加，但请确认）。别信文档说的‘自动生效’，改完等3分钟，然后进实例跑：curl -v https://www.googleapis.com/storage/v1——看到Connected to 169.254.169.254才算真的活了。
第三课：服务边界（Service Perimeter）不是给金融客户准备的，是给你那个‘临时测试环境’兜底的
你有没有过这样的时刻：开发小哥在dev-project里顺手启了个Cloud Run服务，绑了roles/storage.objectAdmin，又把服务账户密钥下载到本地Mac……然后某天他离职交接，忘了删密钥？三个月后，有人用那串密钥扫遍了prod-project的Storage桶。
服务边界就是你的数字结界。它不阻止用户登录Console，但会锁死跨边界的资源访问——比如，把dev-project和prod-project圈进同一个perimeter，再设置‘restricted services’为storage.googleapis.com，那么即使dev的服务账户有objectAdmin权限，它也无法读取prod桶里的任何对象，API直接返回PERMISSION_DENIED。
重点来了：服务边界依赖组织层级（Organization）和Resource Manager API，但你不需要整个公司上阵。一个folders/123456级folder下建两个project，就能玩转。别被‘Enterprise’字眼吓住——它就像个带锁的玻璃柜：柜子透明（你仍能看到资源），但手伸不进去（API调用被拦截）。
第四课：IAM不是‘分配角色’，是‘剪裁权限’的艺术
别再用roles/editor了。这角色包含2000+权限，其中至少1700个你永远用不到。我们曾审计过一个‘运维组’，全员editor，结果有人误删了整个VPC——因为compute.networks.delete就在里面。
正确姿势：用roles/compute.networkUser + roles/compute.securityAdmin + 自定义角色。自定义角色不是炫技，是救命：比如只允许启动特定机器类型（compute.instances.create + condition: resource.instance.machineType.matches('^(n2-standard-4|e2-medium)$')），或者只允许修改带env=staging标签的实例（compute.instances.update + condition on resource labels）。
第五课：Secret Manager不是‘存密码的地方’，是‘权限闸门’
把数据库密码存在环境变量里？恭喜，ps aux | grep password就能看见明文。存在ConfigMap里？K8s RBAC没配严，随便一个dev namespace的pod就能kubectl get cm -n kube-system偷走。
Secret Manager的威力，在于它的访问控制粒度：你可以让一个Service Account只有secretmanager.secrets.get权限，且仅限projects/my-prod/secrets/db-password——注意，是具体secret路径，不是整个secrets/*。更狠的是，它支持自动轮转（对接Cloud KMS）、访问审计（每毫秒一次log）、以及最重要的：不提供‘列出所有secret’权限。攻击者就算拿到token，也不知道有哪些secret可读，只能盲猜。
最后送一句血泪忠告：GCP内网安全，不是堆功能，而是建立‘默认拒绝’肌肉记忆。每次创建资源，先问：它需要对外说话吗？需要谁来访问它？它的身份凭证是否最小化？它的敏感数据是否全程加密且受控？
毕竟，最坚固的防火墙，不是写在Console里的规则，而是工程师敲下--no-address、--no-service-account、--no-scopes时，指尖那一秒的停顿。
