Cilium 系列 -14-Cilium NetworkPolicy 简介

本文最后更新于：2024年7月24日 晚上

系列文章

前言

今天我们进入 Cilium 安全相关主题, 介绍 Kubernetes 网络策略以及 CiliumNetworkPolicies 额外支持的内容。

网络策略 (NetworkPolicy) 的类型

默认情况下，Kubernetes 集群中的所有 pod 都可被其他 pod 和网络端点访问。

网络策略允许用户定义 Kubernetes 集群允许哪些流量, 禁止哪些流量。传统的防火墙是根据源或目标 IP 地址和端口来配置允许或拒绝流量的 (五元组)，而 Cilium 则使用 Kubernetes 的身份信息（如 标签 选择器、命名空间 名称，甚至是完全限定的 域名 ）来定义允许和不允许的流量规则。这样，网络策略就能在 Kubernetes 这样的 动态环境 中运行，因为在这种环境中，IP 地址会随着不同 pod 的创建和销毁而不断被使用和重复使用。

在 Kubernetes 上运行 Cilium 时，可以使用 Kubernetes 资源定义网络策略(networking.k8s.io/v1 NetworkPolicy)。Cilium Agent 将观察 Kubernetes API 服务器是否有网络策略更新，并加载必要的 eBPF 程序和 map，以确保实施所需的网络策略。启用 Cilium 的 Kubernetes 提供三种网络策略格式：

  • 支持第 3 层和第 4 层策略的标准 Kubernetes NetworkPolicy 资源(标准的 Kubernetes NetworkPolicy, Kubernetes 开箱自带, 其他 CNI 如 Calico 也支持)
  • 支持第 3、4 和 7 层（应用层）策略的 CiliumNetworkPolicy 资源(Cilium 专有的 CRD: CiliumNetworkPolicy)
  • CiliumClusterwideNetworkPolicy 资源，用于指定适用于整个集群而非指定命名空间的策略(Cilium 专有的 CRD: CiliumClusterwideNetworkPolicy, 字面意思, 集群范围的网络策略, 甚至可以进行 Node 级别的网络策略限制.)

Cilium 支持同时使用所有这些策略类型。不过，在使用多种策略类型时应小心谨慎，因为在多种策略类型中理解所允许流量的完整集合可能会造成混乱。如果不密切注意，可能会导致意外的策略行为。因此, 推荐在 Cilium 中, 使用后两种资源.

这次我们主要关注 CiliumNetworkPolicy 资源，因为它代表了标准 Kubernetes NetworkPolicy 功能的超集。

NetworkPolicy 资源

NetworkPolicy 资源是 Kubernetes 的标准资源(networking.k8s.io/v1 NetworkPolicy)，可让您在 IP 地址或端口级别（OSI 模型第 3 层或第 4 层）控制流量。NetworkPolicy 的功能包括:

  • 使用标签 (label) 匹配的 L3/L4 Ingress 和 Egress 策略
  • 集群外部端点使用 IP/CIDR 的 L3 IP/CIDR Ingress 和 Egress 策略
  • L4 TCP 和 ICMP 端口 Ingress 和 Egress 策略

🐾Warning

NetworkPolicy 不适用于主机网络命名空间。启用主机网络的 Pod 不受网络策略规则的影响。

网络策略无法阻止来自 localhost 或来自其驻留的节点的流量。

CiliumNetWorkPolicy 资源

CiliumNetworkPolicy 是标准 NetworkPolicy 的扩展。CiliumNetworkPolicy 扩展了标准 Kubernetes NetworkPolicy 资源的 L3/L4 功能，并增加了多项功能：

  • L7 HTTP 协议策略规则，将 Ingress 和 Egress 限制为特定的 HTTP 路径
  • 支持 DNS、Kafka 和 gRPC 等其他 L7 协议
  • 基于服务名称的内部集群通信 Egress 策略
  • 针对特殊实体使用 实体匹配 的 L3/L4 Ingress 和 Egress 策略
  • 使用 DNS FQDN 匹配的 L3 Ingress 和 Egress 策略

您可以在 Cilium 项目文档 中找到针对几种常见用例的 CiliumNetworkPolicy YAML 清单的具体示例。

要读取网络策略的 YAML 定义并预测它将允许和拒绝哪些流量可能比较困难，而且要使策略精确地达到你想要的效果也并非易事。幸运的是，networkpolicy.io 上的可视化策略编辑器能让这一切变得更容易。

Networkpolicy.io 可视化策略编辑器

NetworkPolicy.io 策略编辑器为您提供了探索和制定 L3 和 L4 网络策略的绝佳方式，它以图形方式描述了一个群集，并让您为所需的网络策略类型选择正确的策略元素。策略编辑器支持标准的 Kubernetes NetworkPolicy 和 CiliumNetworkPolicy 资源。

截图如下:

Networkpolicy.io

在顶部，有一个交互式服务地图可视化，您可以用它来创建新策略。绿线表示当前策略定义允许的流量，红线表示拒绝的流量。您可以使用交互式服务地图用户界面配置针对群集内部端点或群集外部端点的入口和出口策略。

左下方是与上述服务地图描述相匹配的网络策略只读 YAML 描述。你可以选择查看标准的 Kubernetes NetworkPolicy 规范或 CiliumNetworkPolicy 规范。你还可以从这里下载策略，用 kubectl 将其应用到你的群集。你还可以上传两种格式的现有策略定义，策略编辑器会更新可视化服务地图表示法，以显示其工作原理。在服务地图用户界面中可视化策略的作用有助于确保策略规则按预期运行。您将有机会在本节后面的实验室中亲自试用 NetworkPolicy 编辑器。

在右下角，编辑器提供了一个教程界面，其中包含了一些常见的情况，可以帮助你思考如何制定策略。您还可以使用该区域上传 Hubble 流量，并根据 Hubble 观察到的情况生成网络策略。

实战

假设这样一个场景:

Kubernetes 集群有多个 NameSpace, 每一个 NameSpace 代表一个租户, 这些租户需要实现租户隔离, 即: 相互之间不可访问. 但是每个租户都允许:

  1. 来自 Ingress 的流量
  2. 来自互联网的流量
  3. 来自监控的抓取

那么策略应该如何设置?

允许来自 Ingress 的流量

NetWorkPolicy: allow-from-ingress

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress

说明如下:

  • 通过 labels 匹配的 Ingress 所在的 NameSpace, 所以需要确保 Ingress 所在的 NameSpace 打上了 policy-group: ingress 的标签.

策略可视化效果如下:

allow-from-ingress

允许来自互联网的流量

🐾Warning

出于安全考虑, 租户 NameSpace 应该只接收来自 Ingress 的业务流量, 而不应该直接允许来自互联网的流量.
本人建议不要启用这条策略.

NetworkPolicy: allow-from-outside

1
2
3
4
5
6
7
8
9
10
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: untitled-policy
spec:
  podSelector: {}
  ingress:
    - from:
        - ipBlock:
            cidr: 0.0.0.0/0

说明如下:

  • cidr 按需调整.

策略可视化效果如下:

allow-from-outside

允许来自监控的流量

NetworkPolicy: allow-from-monitoring

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-monitoring
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group: monitoring
  podSelector: {}
  policyTypes:
  - Ingress

说明如下:

  • 通过 labels 匹配的 Ingress 所在的 NameSpace, 所以需要确保 Ingress 所在的 NameSpace 打上了 policy-group: monitoring 的标签.

策略可视化效果如下:

allow-from-monitoring

允许同一 NameSpace 的流量

NetworkPolicy: allow-same-namespace

1
2
3
4
5
6
7
8
9
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

策略可视化效果如下:

allow-same-namespace

合起来

把上面的都合起来, 具体如下:

NetworkPolicy: tenant-isolation

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  ingress:
    - from:
        - podSelector: {}
    - from:
        - namespaceSelector:
            matchLabels:
              policy-group: ingress
    - from:
        - ipBlock:
            cidr: 0.0.0.0/0
    - from:
        - namespaceSelector:
            matchLabels:
              policy-group: monitoring
    - from:
        - podSelector: {}
  policyTypes:
    - Ingress

转换为 CiliumNetworkPolicy, 内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-same-namespace
spec:
  endpointSelector: {}
  ingress:
    - fromEndpoints:
        - {}
    - fromEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace.labels.policy-group: ingress
    - fromEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace.labels.policy-group: monitoring
    - fromEntities:
        - world

策略可视化效果如下:

tenant-isolation

总结

今天我们进入 Cilium 安全相关主题, 介绍 Kubernetes 网络策略以及 CiliumNetworkPolicies 额外支持的内容。介绍了一款好用的可视化 NetworkPolicy 编辑器: <networkpolicy.io>. 同时通过一个实用的 " 租户隔离 " 网络策略需求来进行演示.