Kubernetes Goat 场景 20 实战用 NetworkPolicy 为集群构建网络边界【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goatKubernetes 默认是扁平网络集群内所有 Pod 之间默认互相可达。本文围绕 Kubernetes Goat 的 Scenario 20完整演示如何编写并应用一条最小化的NetworkPolicy把默认放行的入站流量改为默认拒绝从而在集群内为指定工作负载website服务建立真正的网络安全边界。读完并动手演练后你将掌握podSelector、ingress: []等关键字段的语义以及先验证连通 → 施加策略 → 复验阻断的标准排障流程。场景背景扁平网络与 NSP 的关系如本仓库 场景首页 所述Scenario 20 的目标是deploy a simple network security policy for kubernetes resources to create security boundaries即部署一条简单的网络策略为集群资源建立安全边界。完整的操作指南位于 场景文档并在 README 的场景清单中列为第 20 项Secure network boundaries using NSP。从文档描述可以确认两个关键前提Kubernetes 原生不提供默认网络隔离。集群内部默认是 flat network schema——任何 Pod 都可以访问任何其他 Pod 的端口除非你显式声明策略。NetworkPolicy 需要 CNI 支持才会生效。文档明确要求ensure you must be using a networking solution which supports NetworkPolicy。换言之NetworkPolicy资源只是声明式 API真正在数据面拦截流量的是 CNI 插件。如果你的集群 CNI 不支持该功能策略资源可以正常创建但不会产生任何隔离效果——这一点在演练前必须确认。场景目标文档给出的目标非常聚焦Create a Network Policy to drop the access to thewebsiteservice to complete this scenario.即创建一条 NetworkPolicy阻断drop对website服务的全部访问以此验证边界确实建立。完整实操步骤以下所有命令均继承自 场景指南可在任意支持 NetworkPolicy 的集群上直接复制执行。第 1 步部署 website 工作负载启动一个带appwebsite标签的 Nginx Pod并通过--expose同时创建 Servicekubectl run --imagenginx website --labels appwebsite --expose --port 80这条命令做了三件事创建名为website的 Pod运行nginx镜像打上appwebsite标签——这是后面 NetworkPolicy 中podSelector的匹配依据通过--expose --port 80创建一个名为website的 Service将集群内流量映射到 80 端口这样集群内其他 Pod 可以直接用http://website访问。第 2 步用临时 Pod 验证连通性启动一个临时 Alpine Pod 作为探针模拟集群内其他工作负载发起请求kubectl run --rm -it --imagealpine temp -- sh--rm参数表示该 Pod 退出后自动清理-it进入交互式 shell。进入 shell 后用wget向 website 服务发起一次简单 HTTP 请求wget -qO- http://website此时应能看到 Nginx 的默认欢迎页 HTML 内容说明扁平网络下流量完全畅通第 3 步编写并应用拒绝策略在本地创建策略清单文档中命名为website-deny.yaml内容如下kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: website-deny spec: podSelector: matchLabels: app: website ingress: []关键点解析podSelector.matchLabels: app: website策略作用于所有匹配该标签的 Pod即第 1 步中创建的websitePod。注意选择的是 Pod 而非 Service这是 NetworkPolicy 的标准行为——策略永远绑定到 Pod 集合。ingress: []这是整条策略的灵魂。空数组表示没有任何入站流量规则被允许即对该 Pod 施加默认拒绝default-deny入站流量的语义。只要ingress字段一旦出现哪怕为空该 Pod 的入站就从默认放行切换为白名单模式而空白名单意味着全部拒绝。若省略ingress字段、只写podSelector策略则不会阻断任何流量这是初学者最常踩的坑。本策略未声明policyTypes字段按 API 默认值ingress和egress类型都会生效——即该 Pod 的出站流量同样会被默认拒绝。本场景只需阻断入站访问因此空策略同时拒绝了出方向演练效果不受影响。应用策略kubectl apply -f website-deny.yaml第 4 步复验流量已被阻断再次启动临时 Pod或直接沿用未退出的 temp Pod重复请求并加上 2 秒超时避免长时间挂起kubectl run --rm -it --imagealpine temp -- shwget -qO- --timeout2 http://website这次请求不再返回 HTML而是因超时/连接失败而报错证明 NetworkPolicy 正在数据面丢弃发往website的入站流量第 5 步清理资源按文档给出的顺序删除本次演练创建的全部资源kubectl delete pod website kubectl delete service website kubectl delete networkpolicy website-deny先删工作负载与 Service再删策略避免残留的拒绝策略影响集群中其他同标签资源。结合仓库源码的实现佐证场景内容的组织方式本仓库将场景拆成两层——场景桩文件即 goat-home Hugo 站点内的场景入口仅保留 frontmatter 与一句话说明并提示refer to the Guide与 完整指南Docusaurus 站点中的分步 Walkthrough包含上文全部命令、策略清单与截图。阅读本场景时应以指南文档为准。策略清单的来源从仓库目录结构看scenarios/目录下存放的是各基础设施服务的 Deployment/Job 清单如scenarios/health-check/deployment.yamlScenario 20 的website-deny.yaml并未提交到仓库而是作为演练过程产物由读者在本地创建——这与该场景教学式演示的定位一致重点在于理解字段语义而非固化一份清单。与仓库其他策略机制的对照仓库中还存在另一类策略示例——Kyverno 命名空间 exec 阻断策略它通过准入控制admission control在控制面拦截违规操作而本场景的 NetworkPolicy 作用于数据面的流量转发。两者分别对应 Kubernetes 安全边界中操作层面与通信层面的两种典型手段。关键要点复盘默认放行是风险不写任何 NetworkPolicy 的集群里所有 Pod 两两互通单个工作负载被攻破就等于整张内部网络暴露。ingress: [] 默认拒绝入站策略存在且声明了 ingress才触发白名单语义空白名单即全拒。策略绑定 Pod 标签podSelector决定作用域标签设计如appwebsite因此成为网络边界规划的一部分。CNI 是生效前提NetworkPolicy 只是 API 声明最终由 CNI 在数据面实施演练前需确认所用网络方案支持该特性。验证方法论本场景演示的基线连通 → 施加策略 → 带超时复验 → 按序清理四步法是排查任何 NetworkPolicy 是否生效的标准流程。掌握以上要点后你可以在此基础上进一步扩展按namespaceSelector限制仅某个命名空间可访问、按ipBlock放行特定网段、或对 egress 方向做同等约束——这些都属于同一条 NetworkPolicy API 的白名单规则组合语义与本场景完全一致。【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 20:34:31 · 阅读 1.2k Kubernetes Goat 场景 20 实战：用 NetworkPolicy 为集群构建网络边界
Kubernetes Goat 场景 20 实战用 NetworkPolicy 为集群构建网络边界【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goatKubernetes 默认是扁平网络集群内所有 Pod 之间默认互相可达。本文围绕 Kubernetes Goat 的 Scenario 20完整演示如何编写并应用一条最小化的NetworkPolicy把默认放行的入站流量改为默认拒绝从而在集群内为指定工作负载website服务建立真正的网络安全边界。读完并动手演练后你将掌握podSelector、ingress: []等关键字段的语义以及先验证连通 → 施加策略 → 复验阻断的标准排障流程。场景背景扁平网络与 NSP 的关系如本仓库 场景首页 所述Scenario 20 的目标是deploy a simple network security policy for kubernetes resources to create security boundaries即部署一条简单的网络策略为集群资源建立安全边界。完整的操作指南位于 场景文档并在 README 的场景清单中列为第 20 项Secure network boundaries using NSP。从文档描述可以确认两个关键前提Kubernetes 原生不提供默认网络隔离。集群内部默认是 flat network schema——任何 Pod 都可以访问任何其他 Pod 的端口除非你显式声明策略。NetworkPolicy 需要 CNI 支持才会生效。文档明确要求ensure you must be using a networking solution which supports NetworkPolicy。换言之NetworkPolicy资源只是声明式 API真正在数据面拦截流量的是 CNI 插件。如果你的集群 CNI 不支持该功能策略资源可以正常创建但不会产生任何隔离效果——这一点在演练前必须确认。场景目标文档给出的目标非常聚焦Create a Network Policy to drop the access to thewebsiteservice to complete this scenario.即创建一条 NetworkPolicy阻断drop对website服务的全部访问以此验证边界确实建立。完整实操步骤以下所有命令均继承自 场景指南可在任意支持 NetworkPolicy 的集群上直接复制执行。第 1 步部署 website 工作负载启动一个带appwebsite标签的 Nginx Pod并通过--expose同时创建 Servicekubectl run --imagenginx website --labels appwebsite --expose --port 80这条命令做了三件事创建名为website的 Pod运行nginx镜像打上appwebsite标签——这是后面 NetworkPolicy 中podSelector的匹配依据通过--expose --port 80创建一个名为website的 Service将集群内流量映射到 80 端口这样集群内其他 Pod 可以直接用http://website访问。第 2 步用临时 Pod 验证连通性启动一个临时 Alpine Pod 作为探针模拟集群内其他工作负载发起请求kubectl run --rm -it --imagealpine temp -- sh--rm参数表示该 Pod 退出后自动清理-it进入交互式 shell。进入 shell 后用wget向 website 服务发起一次简单 HTTP 请求wget -qO- http://website此时应能看到 Nginx 的默认欢迎页 HTML 内容说明扁平网络下流量完全畅通第 3 步编写并应用拒绝策略在本地创建策略清单文档中命名为website-deny.yaml内容如下kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: website-deny spec: podSelector: matchLabels: app: website ingress: []关键点解析podSelector.matchLabels: app: website策略作用于所有匹配该标签的 Pod即第 1 步中创建的websitePod。注意选择的是 Pod 而非 Service这是 NetworkPolicy 的标准行为——策略永远绑定到 Pod 集合。ingress: []这是整条策略的灵魂。空数组表示没有任何入站流量规则被允许即对该 Pod 施加默认拒绝default-deny入站流量的语义。只要ingress字段一旦出现哪怕为空该 Pod 的入站就从默认放行切换为白名单模式而空白名单意味着全部拒绝。若省略ingress字段、只写podSelector策略则不会阻断任何流量这是初学者最常踩的坑。本策略未声明policyTypes字段按 API 默认值ingress和egress类型都会生效——即该 Pod 的出站流量同样会被默认拒绝。本场景只需阻断入站访问因此空策略同时拒绝了出方向演练效果不受影响。应用策略kubectl apply -f website-deny.yaml第 4 步复验流量已被阻断再次启动临时 Pod或直接沿用未退出的 temp Pod重复请求并加上 2 秒超时避免长时间挂起kubectl run --rm -it --imagealpine temp -- shwget -qO- --timeout2 http://website这次请求不再返回 HTML而是因超时/连接失败而报错证明 NetworkPolicy 正在数据面丢弃发往website的入站流量第 5 步清理资源按文档给出的顺序删除本次演练创建的全部资源kubectl delete pod website kubectl delete service website kubectl delete networkpolicy website-deny先删工作负载与 Service再删策略避免残留的拒绝策略影响集群中其他同标签资源。结合仓库源码的实现佐证场景内容的组织方式本仓库将场景拆成两层——场景桩文件即 goat-home Hugo 站点内的场景入口仅保留 frontmatter 与一句话说明并提示refer to the Guide与 完整指南Docusaurus 站点中的分步 Walkthrough包含上文全部命令、策略清单与截图。阅读本场景时应以指南文档为准。策略清单的来源从仓库目录结构看scenarios/目录下存放的是各基础设施服务的 Deployment/Job 清单如scenarios/health-check/deployment.yamlScenario 20 的website-deny.yaml并未提交到仓库而是作为演练过程产物由读者在本地创建——这与该场景教学式演示的定位一致重点在于理解字段语义而非固化一份清单。与仓库其他策略机制的对照仓库中还存在另一类策略示例——Kyverno 命名空间 exec 阻断策略它通过准入控制admission control在控制面拦截违规操作而本场景的 NetworkPolicy 作用于数据面的流量转发。两者分别对应 Kubernetes 安全边界中操作层面与通信层面的两种典型手段。关键要点复盘默认放行是风险不写任何 NetworkPolicy 的集群里所有 Pod 两两互通单个工作负载被攻破就等于整张内部网络暴露。ingress: [] 默认拒绝入站策略存在且声明了 ingress才触发白名单语义空白名单即全拒。策略绑定 Pod 标签podSelector决定作用域标签设计如appwebsite因此成为网络边界规划的一部分。CNI 是生效前提NetworkPolicy 只是 API 声明最终由 CNI 在数据面实施演练前需确认所用网络方案支持该特性。验证方法论本场景演示的基线连通 → 施加策略 → 带超时复验 → 按序清理四步法是排查任何 NetworkPolicy 是否生效的标准流程。掌握以上要点后你可以在此基础上进一步扩展按namespaceSelector限制仅某个命名空间可访问、按ipBlock放行特定网段、或对 egress 方向做同等约束——这些都属于同一条 NetworkPolicy API 的白名单规则组合语义与本场景完全一致。【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考