GKE部署仅企业内网可访问Web应用的网络访问控制方案咨询

下面是经过生产验证的落地方案，分层做控制，完全阻断公网访问路径：

1. 入口层根绝公网暴露可能 #

这一层是核心，只要入口没有公网IP，公网流量根本不可能路由到你的应用：

• 所有服务暴露统一使用GCP内部负载均衡（ILB），不要创建公网类型的LoadBalancer。配置Ingress时指定内部Ingress类，或者加注解cloud.google.com/load-balancer-type: "Internal"，这个LB只会分配RFC1918私网地址，不会绑定任何公网IP。
• 节点池全部采用私网节点配置，创建时关闭“分配外部公网IP”选项，节点本身不直接对公网可达，避免绕过LB直接访问节点端口的风险。
• 禁止直接给Pod配置公网IP，工作负载配置里关掉直接公网暴露的相关参数。

2. 多层访问白名单控制 #

光有私网入口不够，要逐层做来源拦截，避免私网内其他非授权资源访问：

• 第一层在VPC防火墙层面配置规则：给ILB、节点池关联的入站规则，仅放通公司办公网出口IP段、云专线打通的IDC网段、VPC内授权的业务网段，所有其他来源的流量直接在防火墙层丢弃，不会进入集群。
• 第二层配置Kubernetes原生NetworkPolicy，针对Web应用的Pod做粒度更细的访问控制，默认拒绝所有入站流量，仅放通授权的来源段和集群内合法调用方。参考配置：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: internal-web-access-control
  namespace: your-app-ns
spec:
  podSelector:
    matchLabels:
      app: your-internal-web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.0.0.0/8 # 替换为实际公司内网主网段
    - ipBlock:
        cidr: 192.168.0.0/16 # 替换为专线互联的IDC/分支网段
    - podSelector:
        matchLabels:
          access-to-internal-web: "allow" # 集群内允许调用的服务标签
    ports:
    - protocol: TCP
      port: 80 # 替换为应用实际监听端口

• 可选第三层挂Cloud Armor策略，就算是内部LB也可以绑定Cloud Armor，直接在策略里拒绝所有公网IP地址段的访问，仅放通备案过的公司内部IP段，多一层防护兜底。

3. 防误配约束与运维规范 #

• 开GCP组织级策略约束：在组织或项目层级配置强制策略，禁止创建公网类型的负载均衡、禁止GKE节点分配公网IP，从API层面直接拦截误操作，就算开发手滑配错了公网入口，请求会直接被平台拒绝，没法创建成功。
• 配置定期巡检规则，每周扫描集群内所有Service、Ingress、Pod资源，排查有没有异常绑定公网IP的资源，发现后立即告警并下线。
• 日常调试不要用kubectl port-forward临时把服务映射到公网，需要远程调试的话走私有连接的IAP身份代理，做严格的身份校验之后再访问，不要开无限制的公网通路。
• 应用层可以加一层轻量的来源IP校验，拿到请求的真实源IP后判断是否属于授权的内网段，非授权来源直接返回403，作为最后一道兜底防线。

核心原则：不要试图靠应用层的账号密码、认证逻辑来防护公网暴露风险。只要应用对公网路由可达，就会面临漏洞扫描、暴力破解、0day漏洞利用的风险，最稳妥的方案就是从网络层直接切断公网到应用的所有路由路径，公网流量连TCP握手都完不成，自然不存在非法访问的可能。

内容的提问来源于stack exchange，提问作者zen2012