Kubernetes NetworkPolicy 你需要了解的内容

随着越来越多的云原生应用程序通过 Kubernetes 的采用进入生产环境，安全性是您在流程早期必须考虑的重要检查点。 在设计云原生应用程序时，嵌入安全策略非常重要。 否则会导致挥之不去的安全问题，从而导致项目延误，并最终给您带来不必要的压力和金钱损失。

多年来，人们一直将安全性放在最后——直到他们的部署即将投入生产。 这种做法会导致交付物延误，因为每个组织都有必须遵守的安全标准，这些标准要么被绕过，要么没有遵守，并且接受了许多风险以完成交付物。

对于刚开始学习 Kubernetes 实现的来龙去脉的人来说，理解 Kubernetes NetworkPolicy 可能会让人望而却步。 但这是您在将应用程序部署到 Kubernetes 集群之前必须学习的基本要求之一。 在学习 Kubernetes 和云原生应用程序模式时，请记住您的口号“不要把安全性抛在脑后！”

NetworkPolicy 概念

NetworkPolicy 替换了数据中心环境中您所熟悉的防火墙设备——例如 pod 到计算实例，网络插件到路由器和交换机，以及卷到存储区域网络 (SAN)。

默认情况下，Kubernetes NetworkPolicy 允许 pod 接收来自任何地方的流量。 如果您不关心 pod 的安全性，那么这可能没问题。 但是，如果您正在运行关键工作负载，那么您需要保护您的 pod。 控制集群内流量（包括入口和出口流量）的方式是通过 NetworkPolicy。

要启用 NetworkPolicy，您需要一个支持 NetworkPolicy 的 网络插件。 否则，您应用的任何规则都将变得毫无用处。

有不同的网络插件在 Kubernetes.io 上列出

• CNI 插件：遵守 Container Network Interface (CNI) 规范，专为互操作性而设计。
  • Kubernetes 遵循 CNI 规范的 v0.4.0 版本。
• Kubernetes 插件：使用 bridge 和 host-local CNI 插件实现基本的 cbr0。

应用网络策略

要应用网络策略，您需要一个可以正常工作的 Kubernetes 集群，其中包含一个支持 NetworkPolicy 的网络插件。

但首先，您需要了解如何在 Kubernetes 上下文中使用 NetworkPolicy。 Kubernetes NetworkPolicy 允许 pod 接收来自任何地方的流量。 这并不理想。 要保护 pod，您必须了解 pod 可以在 Kubernetes 构造中通信的端点。

1. 使用 podSelector 进行 Pod 到 Pod 的通信。
   

   - namespaceSelector:
       matchLabels:
         project: myproject

2. 使用 namespaceSelector 和/或 podSelector 和 namespaceSelector 的组合进行命名空间到命名空间的通信以及命名空间到 Pod 的通信。
   

   - namespaceSelector:
       matchLabels:
         project: myproject
   - podSelector:
       matchLabels:
         role: frontend

3. 使用 ipBlock 进行 Pod 的 IP 块通信，以定义哪个 IP CIDR 块决定了源和目标。
   

   - ipBlock:
           cidr: 172.17.0.0/16
           except:
           - 172.17.1.0/24

请注意基于 Pod、命名空间和 IP 的策略之间的区别。 对于基于 Pod 和命名空间的 NetworkPolicy，您使用 selector 来控制流量，而对于基于 IP 的 NetworkPolicy，则使用 IP blocks（CIDR 范围）定义控件。

总而言之，NetworkPolicy 应如下所示

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 192.168.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

参考上面的 NetworkPolicy，请注意 spec 部分。 在此部分下，带有标签 app=backend 的 podSelector 是我们 NetworkPolicy 的目标。 简而言之，NetworkPolicy 保护给定命名空间内的名为 backend 的应用程序。

此部分还具有 policyTypes 定义。 此字段指示给定的策略是否适用于选定 Pod 的入口流量、选定 Pod 的出口流量，或两者兼而有之。

spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress

现在，看一下 ingress 和 egress 部分。 此定义决定了 NetworkPolicy 的控制。

首先，检查 ingress from 部分。

在这种情况下，NetworkPolicy 允许来自以下位置的 pod 连接

• ipBlock
  • 允许 172.17.0.0/16
  • 拒绝 192.168.1.0/24
• namespaceSelector
  • myproject: 允许来自此命名空间的所有 Pod，并且具有相同的标签 project=myproject。
• podSelector
  • frontend: 允许匹配标签 role=frontend 的 Pod

ingress:
- from:
  - ipBlock:
      cidr: 172.17.0.0/16
      except:
      - 192.168.1.0/24
  - namespaceSelector:
      matchLabels:
        project: myproject
  - podSelector:
      matchLabels:
        role: frontend

现在，检查 egress to 部分。 这决定了从 Pod 到以下位置的连接

• ipBlock
  • 10.0.0.0/24：允许连接到此 CIDR
  • 端口：允许使用 TCP 和端口 5978 连接

egress:
- to:
  - ipBlock:
      cidr: 10.0.0.0/24
  ports:
  - protocol: TCP
    port: 5978

NetworkPolicy 限制

仅靠 NetworkPolicy 无法完全保护您的 Kubernetes 集群。 您可以使用操作系统组件或第 7 层技术来克服已知的限制。 您需要记住，NetworkPolicy 只能处理 IP 地址和端口级别的安全性——开放系统互连 (OSI) 第 3 层或第 4 层。

要解决 NetworkPolicy 无法处理的安全要求，您需要使用其他安全解决方案。 以下是一些 用例，您需要了解 NetworkPolicy 需要其他技术来增强。

总结

了解 Kubernetes NetworkPolicy 非常重要，因为它是实现（但不是替代）您通常在数据中心设置中使用的防火墙角色的方法，但适用于 Kubernetes。 将其视为容器安全的第一层，要知道仅靠 NetworkPolicy 并不是一个完整的安全解决方案。

NetworkPolicy 使用选择器和标签在 Pod 和命名空间上应用安全。 此外，NetworkPolicy 还可以通过 IP 范围强制执行安全。

对 NetworkPolicy 有充分的了解是在 Kubernetes 上下文中安全采用容器化的重要技能。