使用 Kubernetes NetworkPolicy 为 Online Boutique 微服务实施最小权限网络隔离以 microservices-demo 为例【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo本文基于 microservices-demo 仓库中 kustomize/components/network-policies/README.md 及其配套的 13 份 NetworkPolicy 清单完整讲解如何为 Online Boutique一个包含 10 个微服务的云原生示例应用启用细粒度的 Pod 间网络访问控制。读者读完本文后将掌握基于 Kustomize Component 一键接入默认拒绝default-deny策略、按调用方白名单收敛 Ingress 流量、以及在本集群与 GKE 集群中验证与排障的完整实战方案。一、背景为什么微服务应用需要 NetworkPolicy在 Kubernetes 集群中默认情况下任意 Pod 都可以与集群内任意其他 Pod、Service 互通即所谓的扁平网络。对于 Online Boutique 这类包含 10 个微服务adservice、cartservice、checkoutservice、currencyservice、emailservice、frontend、loadgenerator、paymentservice、productcatalogservice、recommendationservice、shippingservice加一个 redis-cart 缓存的分布式应用这种全通模式意味着任何一个被攻破的工作负载都可以横向访问集群内所有服务无法基于业务依赖关系建立最小权限边界审计和合规场景下缺少显式的通信清单。Kubernetes 原生的 NetworkPolicy 资源正是为解决这一问题而设计它通过podSelector选择目标 Pod 集合通过ingress/egress规则声明允许的流量来源与去向由集群内的 CNI 插件负责实际强制执行。microservices-demo 仓库在 kustomize/components/network-policies/ 目录下提供了一套开箱即用的策略集合采用每个 Deployment 一张策略的细粒度模型本文接下来逐层展开。二、前置条件选择支持 NetworkPolicy 强制执行的集群环境NetworkPolicy 清单本身是标准的networking.k8s.io/v1资源但强制执行能力取决于集群使用的 CNI 插件。原文档明确给出了两类推荐环境1. Google Kubernetes EngineGKE——推荐方案在 GKE 上启用 NetworkPolicy 强制执行的推荐方式是使用 GKE Dataplane V2。Dataplane V2 基于 eBPF 与 Cilium 实现天然支持 NetworkPolicy无需额外安装 Calico 等第三方插件同时还能提供网络策略日志能力。从 GKE 1.18 起 Dataplane V2 已正式 GA创建集群时启用--enable-dataplane-v2即可gcloud container clusters create boutique-cluster \ --enable-dataplane-v2 \ --enable-ip-alias2. 本地开发环境minikube——Calico CNI若在本地使用 minikube 验证策略需要切换到支持 NetworkPolicy 的替代 CNI官方建议使用 Calico。启动命令非常简单minikube start --cnicalico需要特别说明的是minikube 默认的 CNIKindnet由aojea/kindnet提供按设计不支持 NetworkPolicy因此如果直接minikube start而不加--cnicalico即使kubectl apply了策略也不会真正生效这是本地验证时最容易踩的坑。部署前建议通过kubectl get networkpolicy确认 API 可用并在应用后实际测试流量是否被拦截以验证底层 CNI 确实在强制执行。三、通过 Kustomize Component 一键接入网络策略microservices-demo 将网络策略封装为一个标准的 Kustomize Componentkustomization.yaml其kind为Component、apiVersion为kustomize.config.k8s.io/v1alpha1resources字段列出了全部 13 份策略清单apiVersion: kustomize.config.k8s.io/v1alpha1 kind: Component resources: - network-policy-deny-all.yaml - network-policy-adservice.yaml - network-policy-cartservice.yaml - network-policy-checkoutservice.yaml - network-policy-currencyservice.yaml - network-policy-emailservice.yaml - network-policy-frontend.yaml - network-policy-loadgenerator.yaml - network-policy-paymentservice.yaml - network-policy-productcatalogservice.yaml - network-policy-recommendationservice.yaml - network-policy-redis.yaml - network-policy-shippingservice.yaml1. 将组件挂载到根 Kustomization从仓库根目录的kustomize/文件夹下执行kustomize edit add component components/network-policies执行后仓库根级的 kustomization.yaml 会被更新为类似下面的内容resources 引用basecomponents 挂载网络策略组件apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: - components/network-policiesKustomize 会保证base中的 Deployment / Service / ConfigMap 等资源与 Component 中的 NetworkPolicy 被合并渲染为最终清单且 Component 的加入不会破坏 base 的复用性——这也是将网络策略独立封装为 Component 而非直接写入 base 的核心价值应用层基线base与安全加固层component解耦可以按环境自由组合例如测试环境不加、生产环境加。2. 渲染与部署本地渲染检查kubectl kustomize .直接部署kubectl apply -k .如果只想查看网络策略部分可以结合kubectl kustomize . | grep -A 30 kind: NetworkPolicy之类的过滤进行核对。3. 验证部署结果部署完成后使用如下命令确认所有策略都已创建kubectl get networkpolicy预期输出与本仓库实际清单一一对应NAME POD-SELECTOR AGE adservice appadservice 2m58s cartservice appcartservice 2m58s checkoutservice appcheckoutservice 2m58s currencyservice appcurrencyservice 2m58s deny-all none 2m58s emailservice appemailservice 2m58s frontend appfrontend 2m58s loadgenerator apploadgenerator 2m58s paymentservice apppaymentservice 2m58s productcatalogservice appproductcatalogservice 2m58s recommendationservice apprecommendationservice 2m58s redis-cart appredis-cart 2m58s shippingservice appshippingservice 2m58s可以看到策略的POD-SELECTOR与 base 中 Deployment 的app标签一一对应deny-all的选择器为none即{}匹配所有 Pod。四、策略模型剖析默认拒绝 按调用方白名单本仓库的策略设计遵循经典的默认拒绝default-deny 白名单开放安全模型共 13 份策略按职责可分为三层。1. 全局兜底策略deny-allnetwork-policy-deny-all.yaml 是整套策略的基石apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} # 选择命名空间内所有 Pod policyTypes: - Ingress - Egress # 同时覆盖入站与出站关键点在于该策略只声明了policyTypes没有任何ingress/egress规则。在 NetworkPolicy 语义中一旦为某类流量声明了策略类型但未提供规则就意味着拒绝所有该类流量。由于podSelector: {}匹配全部 Pod它等效于在命名空间级别建立了一道默认全拒的防火墙基线任何没有配套白名单策略的工作负载默认无法被访问、也无法对外访问。需要指出NetworkPolicy 是增量叠加的每个匹配的 Policy 都会生效规则之间是或关系。deny-all 保证没有策略就没有流量而下面的每个服务策略负责为被允许的调用方放行二者叠加得到最终结果。2. 入口暴露策略frontend 与 loadgeneratornetwork-policy-frontend.yamlspec: podSelector: matchLabels: app: frontend policyTypes: - Ingress - Egress ingress: - {} egress: - {}ingress: - {}表示允许来自任意来源的入站流量结合 frontend.yaml 中通过 LoadBalancer/Ingress 暴露 8080 端口的设定egress: - {}允许任意出站。作为用户入口网关frontend 需要自由调用各后端服务因此对其保持全通。network-policy-loadgenerator.yaml 比较特殊它只有Egress策略类型没有 Ingress——因为压测负载生成器locustfile.py只负责主动向 frontend 发起请求不需要被任何服务访问而出站保持全通以允许其访问 frontend Service 以及必要的控制面/DNS 出口。3. 后端服务白名单策略其余 9 份策略adservice、cartservice、checkoutservice、currencyservice、emailservice、paymentservice、productcatalogservice、recommendationservice、shippingservice加上 redis-cart全部遵循同一模式Ingress 只放行业务上确需调用的调用方且精确到 TCP 端口Egress 全通。以 network-policy-cartservice.yaml 为例spec: podSelector: matchLabels: app: cartservice policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: app: frontend - podSelector: matchLabels: app: checkoutservice ports: - port: 7070 protocol: TCP egress: - {}该策略声明只有app: frontend和app: checkoutservice的 Pod 可以访问 cartservice 的 7070 端口gRPC 服务端口见 kustomize/base/cartservice.yaml 中的 Service/容器端口配置其他 Pod 一律被拒。4. 完整的调用关系矩阵综合全部策略可以得到 Online Boutique 在启用网络策略后的受控调用关系白名单矩阵Ingress 方向端口均为 TCP目标服务NetworkPolicy允许的调用方podSelector 白名单端口deny-all无兜底全拒-frontend任意ingress: - {}入口网关任意loadgenerator无 Ingress 规则仅出站压测-adservicefrontend9555cartservicefrontend、checkoutservice7070checkoutservicefrontend5050currencyservicefrontend、checkoutservice7000emailservicecheckoutservice8080paymentservicecheckoutservice50051productcatalogservicefrontend、checkoutservice、recommendationservice3550recommendationservicefrontend8080redis-cartcartservice6379shippingservicefrontend、checkoutservice50051将这张矩阵与业务调用链用户经 frontend 浏览商品/推荐 → 结算时 checkoutservice 依次调用 cart/currency/email/payment/shipping/productcatalog对照可以清晰看到策略白名单精确刻画了应用的真实依赖图这正是最小权限原则在 Kubernetes 网络层的落地被白名单外的任何 Pod 访问都会在 CNI 层被静默丢弃即使应用层不设防攻击面也被大幅收敛。五、Egress 保持全通的设计考量原文档特别用 Note 强调了这些 NetworkPolicy 的 Egress 是刻意保持全开egress: - {}的。这并非疏漏而是基于 Online Boutique 实际运行形态的务实取舍——它的出站目的地种类较多逐一收敛的成本与风险不成比例主要包括Kubernetes CoreDNS所有 Pod 都需要向集群 DNSkube-system 命名空间的kube-dns/coredns发起解析否则服务发现如adservice:9555这样的 Service DNS 名将不可用Istio 控制面istiod如果叠加了 service-mesh-istio 组件每个注入 sidecar 的 Pod 都需要与 istiod 通信获取证书与配置下发Google Cloud 可观测性 API在 GKE 上运行时应用还会向 Cloud Trace、Cloud Profiler 等 API 上报遥测数据仓库中 google-cloud-operations 组件即与可观测性相关istio-proxy 与本地运维流量sidecar 场景下容器间经 localhost 的通信、健康检查探针等也需要保留。读者若在生产环境追求更严格的出站收敛可以在此基础上按需为 Egress 增加to规则例如只放行kube-system命名空间下的kube-dnsService但需自行评估上述依赖项的完整清单避免因误拒导致服务不可用。六、结合仓库其他组件编排完整的安全拓扑网络策略组件可以与本仓库中其他 Kustomize Component 自由组合构建更完整的安全与可观测拓扑service-mesh-istio 组件kustomize/components/service-mesh-istio/为应用接入 Istio service mesh。注意 NetworkPolicy 与 sidecar 共存时Pod 的流量会先经过 istio-proxy 再出网若同时启用 Egress 收敛需将 istiod、DNS 等纳入to规则本仓库策略将 Egress 全开正是为了与 mesh 场景兼容。网络策略与 Service 的关系NetworkPolicy 的端口匹配基于目标 Pod 实际监听的端口containerPort而非 Service 的 targetPort 概念上表中的端口均与 kustomize/base/ 中各 Deployment 的containerPort及 gRPC 服务监听端口一致如 adservice 9555、checkoutservice 5050、productcatalogservice 3550 等可对照 demo.proto 中的服务定义验证。验证与测试策略生效后可借助kubectl run一个临时 Pod或直接kubectl exec进任意 Pod尝试nc -vz service port被策略拒绝的端口将表现为连接超时/无响应而被放行的端口如 frontend → productcatalogservice:3550可正常连通以此确认白名单矩阵与上文表格一致。七、小结通过 microservices-demo 的 network-policies 组件我们完成了一次完整的微服务最小权限网络隔离落地用deny-all建立默认拒绝基线用每服务一份 NetworkPolicy 精确刻画业务调用依赖Ingress 收敛到调用方 端口白名单Egress 出于 DNS、istiod、云可观测 API 等依赖而刻意全开并有明确注释说明缘由全程通过 Kustomize Component 与 base 解耦一条命令即可在 GKE Dataplane V2 或 minikube Calico 环境完成接入与验证。这种默认拒绝 白名单矩阵的模式可以直接迁移到任何微服务架构的 Kubernetes 集群作为纵深防御体系中网络层的第一道闸门。【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考