使用 Cilium 增强 Kubernetes 网络安全

Posted 2022-02-16 CNCF

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了使用 Cilium 增强 Kubernetes 网络安全相关的知识，希望对你有一定的参考价值。

TL;DR

在本篇，我们分别使用了 Kubernetes 原生的网络策略和 Cilium 的网络策略实现了 Pod 网络层面的隔离。不同的是，前者只提供了基于 L3/4 的网络策略；后者支持 L3/4、L7 的网络策略。

通过网络策略来提升网络安全，可以极大降低了实现和维护的成本，同时对系统几乎没有影响。

尤其是基于 eBPF 技术的 Cilium，解决了内核扩展性不足的问题，从内核层面为工作负载提供安全可靠、可观测的网络连接。

背景

为什么说 Kubernetes 网络存在安全隐患？集群中的 Pod 默认是未隔离的，也就是 Pod 之间的网络是互通的，可以互相通信的。

这里就会有问题，比如由于数据敏感服务 B 只允许特定的服务 A 才能访问，而服务 C 无法访问 B。要禁止服务 C 对服务 B 的访问，可以有几种方案：

在 SDK 中提供通用的解决方案，实现白名单的功能。首先请求要带有来源的标识，然后服务端可以接收规则设置放行特定标识的请求，拒绝其他的请求。

云原生的解决方案，使用服务网格的 RBAC、mTLS 功能。RBAC 实现原理与应用层的 SDK 方案类似，但是属于基础设施层的抽象通用方案；mTLS 则会更加复杂一些，在连接握手阶段进行身份验证，涉及证书的签发、验证等操作。

以上两种方案各有利弊：

SDK 的方案实现简单，但是规模较大的系统会面临升级推广困难、多语言支持成本高等问题。

服务网格的方案是基础设施层的通用方案，天生支持多语言。但是对于未落地网格的用户来说，架构变化大，成本高。如果单纯为了解决安全问题，使用网格方案性价比又很低，且不说现有网格实现等落地难度大及后期的使用维护成本高。

继续向基础设施下层找方案，从网络层入手。Kubernetes 提供了的网络策略 *NetworkPolicy*^[1]，则可以实现“网络层面的隔离”。

示例应用

在进一步演示 NetworkPolicy 的方案之前，先介绍用于演示的示例应用。我们使用 Cilium 在互动教程 Cilium getting started^[2] 中使用的“星球大战”场景。

这里有三个应用，星战迷估计不会陌生：

死星 deathstar：在 80 端口提供 web 服务，有 2 个副本，通过 Kubernetes Service 的负载均衡为帝国战机对外提供”登陆“服务。

钛战机 tiefighter：执行登陆请求。

X翼战机 xwing：执行登陆请求。

如图所示，我们使用了 Label 对三个应用进行了标识：org 和 class。在执行网络策略时，我们会使用这两个标签识别负载。

# app.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: deathstar
  labels:
    app.kubernetes.io/name: deathstar
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    org: empire
    class: deathstar
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deathstar
  labels:
    app.kubernetes.io/name: deathstar
spec:
  replicas: 2
  selector:
    matchLabels:
      org: empire
      class: deathstar
  template:
    metadata:
      labels:
        org: empire
        class: deathstar
        app.kubernetes.io/name: deathstar
    spec:
      containers:
      - name: deathstar
        image: docker.io/cilium/starwars
---
apiVersion: v1
kind: Pod
metadata:
  name: tiefighter
  labels:
    org: empire
    class: tiefighter
    app.kubernetes.io/name: tiefighter
spec:
  containers:
  - name: spaceship
    image: docker.io/tgraf/netperf
---
apiVersion: v1
kind: Pod
metadata:
  name: xwing
  labels:
    app.kubernetes.io/name: xwing
    org: alliance
    class: xwing
spec:
  containers:
  - name: spaceship
    image: docker.io/tgraf/netperf

Kubernetes 网络策略

可以通过官方文档^[3]获取更多详细信息，这里我们直接放出配置：

# native/networkpolicy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      org: empire
      class: deathstar
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          org: empire
    ports:
    - protocol: TCP
      port: 80

podSelector ：表示要应用网络策略的工作负载均衡，通过 label 选择到了 deathstar 的 2 个 Pod。

policyTypes ：表示流量的类型，可以是 Ingress 或 Egress 或两者兼具。这里使用 Ingress，表示对选择的 deathstar Pod 的入站流量执行规则。

ingress.from：表示流量的来源工作负载，也是使用 podSelector 和 Label 进行选择，这里选中了 org=empire 也就是所有“帝国的战机”。

ingress.ports：表示流量的进入端口，这里列出了 deathstar 的服务端口。

接下来，我们测试下。

测试

先准备环境，我们使用 K3s^[4] 作为 Kubernetes 环境。但由于 K3s 默认的 CNI 插件 Flannel 不支持网络策略，我们需要换个插件，这里选择 Calico^[5]，即 K3s + Calico 的方案。

先创建一个单节点的集群：

curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" INSTALL_K3S_EXEC="--flannel-backend=none --cluster-cidr=10.42.0.0/16 --disable-network-policy --disable=traefik" sh -

此时，所有的 Pod 都处于 Pending 状态，因为还需要安装 Calico：

kubectl apply -f https://projectcalico.docs.tigera.io/manifests/calico.yaml

待 Calico 成功运行后，所有的 Pod 也会成功运行。

接下来就是部署应用：

kubectl apply -f app.yaml

执行策略前，执行下面的命令看看“战机能否登陆死星”：

kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
Ship landed

kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
Ship landed

从结果来看，两种 ”战机“（Pod 负载）都可以访问 deathstar 服务。

此时执行网络策略：

kubectl apply -f native/networkpolicy.yaml

再次尝试”登陆“，xwing 的登陆请求会停在那（需要使用 ctrl+c 退出，或者请求时加上 --connect-timeout 2）。

思考

使用 Kubernetes 网络策略实现了我们想要的，从网络层面为服务增加了白名单的功能，这种方案没有改造成本，对系统也几乎无影响。

Cilium 还没出场就结束了？我们继续看：

有时我们的服务会对外暴露一些管理端点，由系统调用执行一些管理上的操作，比如热更新、重启等。这些端点是不允许普通服务来调用，否则会造成严重的后果。

比如示例中，tiefighter 访问了 deathstar 的管理端点 /exhaust-port：

kubectl exec tiefighter -- curl -s -XPUT deathstar.default.svc.cluster.local/v1/exhaust-port
Panic: deathstar exploded

goroutine 1 [running]:
main.HandleGarbage(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa)
        /code/src/github.com/empire/deathstar/
        temp/main.go:9 +0x64
main.main()
        /code/src/github.com/empire/deathstar/
        temp/main.go:5 +0x85

出现了 Panic 错误，检查 Pod 你会发现 dealthstar 挂了。

Kubernetes 的网络策略仅能工作在 L3/4 层，对 L7 层就无能为力了。

还是要请出 Cilium。

Cilium 网络策略

由于 Cilium 涉及了 Linux 内核、网络等众多知识点，要讲清实现原理篇幅极大。故这里仅摘取了官网的介绍，后期希望有时间再写一篇关于实现的。

Cilium 简介

Cilium^[6] 是一个开源软件，用于提供、保护和观察容器工作负载（云原生）之间的网络连接，由革命性的内核技术 eBPF^[7] 推动。

eBPF 是什么？

Linux 内核一直是实现监控/可观测性、网络和安全功能的理想地方。不过很多情况下这并非易事，因为这些工作需要修改内核源码或加载内核模块，最终实现形式是在已有的层层抽象之上叠加新的抽象。eBPF 是一项革命性技术，它能在内核中运行沙箱程序（sandbox programs），而无需修改内核源码或者加载内核模块。

将 Linux 内核变成可编程之后，就能基于现有的（而非增加新的）抽象层来打造更加智能、功能更加丰富的基础设施软件，而不会增加系统的复杂度，也不会牺牲执行效率和安全性。

我们来看下 Cilium 的网络策略：

# cilium/networkpolicy-L4.yaml
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "L7 policy to restrict access to specific HTTP call"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
  - fromEndpoints:
    - matchLabels:
        org: empire
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP

与 Kubernetes 的原生网络策略差异不大，参考前面的介绍也都看懂，我们直接进入测试。

测试

由于 Cilium 本身就实现了 CNI，所以之前的集群就不能用了，先卸载集群：

k3s-uninstall.sh
# ！！！切记要清理之前的 cni 插件
sudo rm -rf /etc/cni/net.d

还是使用同样的命令创建单节点的集群：

curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" INSTALL_K3S_EXEC="--flannel-backend=none --cluster-cidr=10.42.0.0/16 --disable-network-policy --disable=traefik" sh -

# cilium 会使用该变量
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

接下来安装 Cilium CLI：

curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz,.sha256sum
sha256sum --check cilium-linux-amd64.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz,.sha256sum

cilium version
cilium-cli: v0.10.2 compiled with go1.17.6 on linux/amd64
cilium image (default): v1.11.1
cilium image (stable): v1.11.1
cilium image (running): unknown. Unable to obtain cilium version, no cilium pods found in namespace "kube-system"

安装 Cilium 到集群：

cilium install

待 Cilium 成功运行：

cilium status
    /¯¯\\
 /¯¯\\__/¯¯\\    Cilium:         OK
 \\__/¯¯\\__/    Operator:       OK
 /¯¯\\__/¯¯\\    Hubble:         disabled
 \\__/¯¯\\__/    ClusterMesh:    disabled
    \\__/

Deployment        cilium-operator    Desired: 1, Ready: 1/1, Available: 1/1
DaemonSet         cilium             Desired: 1, Ready: 1/1, Available: 1/1
Containers:       cilium             Running: 1
                  cilium-operator    Running: 1
Cluster Pods:     3/3 managed by Cilium
Image versions    cilium-operator    quay.io/cilium/operator-generic:v1.11.1@sha256:977240a4783c7be821e215ead515da3093a10f4a7baea9f803511a2c2b44a235: 1
                  cilium             quay.io/cilium/cilium:v1.11.1@sha256:251ff274acf22fd2067b29a31e9fda94253d2961c061577203621583d7e85bd2: 1

部署应用：

kubectl apply -f app.yaml

待应用启动后测试服务调用：

kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
Ship landed
kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
Ship landed

执行 L4 网络策略：

kubectl apply -f cilium/networkpolicy-L4.yaml

再次尝试“登陆”死星，xwing 战机同样无法登陆，说明 L4 层的规则生效。

我们再尝试 L7 层的规则：

# cilium/networkpolicy-L7.yaml
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "L7 policy to restrict access to specific HTTP call"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
  - fromEndpoints:
    - matchLabels:
        org: empire
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/v1/request-landing"

执行规则：

kubectl apply -f cilium/networkpolicy-L7.yaml

这回，使用 tiefighter 调用死星的管理接口：

kubectl exec tiefighter -- curl -s -XPUT deathstar.default.svc.cluster.local/v1/exhaust-port
Access denied
# 登陆接口工作正常
kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
Ship landed

这回返回了 Access denied，说明 L7 层的规则生效了。

参考资料

[1]

网络策略 NetworkPolicy: https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/

[2]

Cilium getting started: https://play.instruqt.com/isovalent/tracks/cilium-getting-started

[3]

官方文档: https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/

[4]

K3s: https://k3s.io

[5]

Calico: https://www.tigera.io/project-calico/

[6]

Cilium: https://cilium.io

[7]

eBPF: https://ebpf.io

文章转载自云原生指北。点击这里阅读原文了解更多。

CNCF概况（幻灯片）

扫描二维码联系我们！

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。

CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请长按以下二维码进行关注。

使用CalicoFlannelWeave和Cilium的终极指南

即使对于经验丰富的 Kubernetes 用户来说，Kubernetes 网络也可能是一个令人生畏的话题。在这篇文章中，我们将深入探讨可用于 Kubernetes 的最流行的容器网络解决方案。在深入研究每个网络解决方案的细节之前，我们将粗略地了解一下 Kubernetes 网络和容器网络接口 (CNI) 规范。我们将讨论为什么网络是一个复杂的问题，以及 CNI 规范如何允许在 Kubernetes 项目之外开发专门的解决方案。

一旦我们对 Kubernetes 网络和 CNI 规范有了很好的了解，我们将剖析一些最流行的容器网络解决方案，包括 flannel、calico、weave 和 cilium。我们将讨论是什么让每个解决方案独一无二，并涵盖解决方案提供的特定功能以及部署解决方案的潜在挑战。最后，你将对每种网络解决方案提供的内容以及如何为你的项目选择正确的 Kubernetes 网络解决方案有一个更好的了解。

Kubernetes 网络

正如我们已经提到的，网络是一个复杂的问题。

Kubernetes 将其网络建立pod 级别–在每个 pod 获取 IP 地址。该模型的优点是你无需担心在 pod 之间创建链接或将容器端口映射到主机端口等。但是你需要确保pod 可以与其他 pod 通信，并且节点可以与 pod 通信而无需需要网络地址转换 (NAT)。该模型的好处是它与 VM网络模型的兼容性。如果你的应用程序以前在 VM 中工作，那么几乎可以保证它可以在 Kubernetes 上运行的 pod 中工作。

网络要求差异很大，具体取决于每个应用程序的需求。Kubernetes 不是在单个解决方案中解决所有这些需求，而是将网络从 Kubernetes 本身中抽象出来，允许供应商构建特定的解决方案来满足不同的需求，并且用户可以将他们想要的网络解决方案插入到他们的集群中。

为什么选择 CNI

linux 容器技术和容器网络不断发展，以适应在不同环境中运行的各种应用程序的需求。为了在一端实现各种网络解决方案与另一端不同容器运行时和容器编排平台之间的集成，而不是重复使网络可插入的努力，容器网络接口 ( CNI ) 的创建是为了在容器执行和网络层之间定义一个标准化的通用接口。

CNI 项目是云原生计算基金会 (CNCF) 的一部分。CNI 规范描述了如何为 Linux 容器配置网络接口。它将其重点领域定义为仅限于容器网络连接并在容器消失时移除分配的资源。由于这个重点，CNI 规范简单并被广泛采用，支持大量插件。许多容器编排框架，包括 Kubernetes，都实现了这个规范。如果你想了解有关 CNI 规范、使用它的运行时以及实现它的第三方插件的更多信息，CNI GitHub 项目是一个很好的起点。

CNI 插件必须符合 CNI 规范定义的标准。每个实现 CNI 规范的插件都试图解决容器网络的不同方面。识别和配置正确的插件或插件组合以满足你的项目需求至关重要。接下来，我们将深入研究四个最受欢迎的 Kubernetes 网络插件，并探讨它们的优缺点。

这些插件是：

Flannel
Calico
Weave
Cilium

Flannel

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wnOBHgSq-1647251656576)(https://platform9.com/wp-content/uploads/2021/06/flannel-horizontal-color.svg)]

CoreOS 创建了Flannel作为 Kubernetes 的首批 CNI 实现之一。因此，它是可用的最古老和最成熟的 CNI 插件之一。由于其简单性和易用性，它也是你的第一个 Kubernetes 集群网络的绝佳入门级选择。Flannel 提供对基本网络功能的访问，并且需要有限的管理来设置和维护。

Flannel 在 Kubernetes 集群的所有节点上运行一个简单的覆盖网络。它在第 3 层（ OSI 网络模型的网络层）提供网络。

**Flannel 支持 VXLAN 作为其默认后端，但你也可以将其配置为使用 UDP 和 host-gw。**AWS VPC、AliVPC、IPIP 和 IPSec 等一些实验性后端也可用，但目前尚未得到官方支持。

Flannel 的缺点之一是缺乏高级功能，例如配置网络策略和防火墙的能力。因此 Flannel 是 Kubernetes 集群网络的一个很好的入门级选择，但是，如果你正在寻找高级网络功能，你可能需要考虑其他 CNI 选项，例如 Calico。

Calico

Calico 以其吉祥物“Felix”为代表，是由Tigera创建的开源项目。Calico 支持广泛的平台，包括 Kubernetes。Calico 项目托管在GitHub 上，并拥有大量详尽的文档。Tigera 还提供了 Calico 的付费企业版。Platform9 还在Platform9 托管 Kubernetes 的付费版本中提供 Calico 作为完全托管的解决方案。托管解决方案使你可以访问 Calico 的所有特性和功能，但无需管理 Calico 配置和维护的复杂性。

Calico 已成为 Kubernetes 集群网络中最受欢迎的 CNI 插件之一。该项目以可靠、灵活和支持 Kubernetes 集群的高性能网络而赢得声誉。

与 Flannel 一样，**Calico 在 OSI 模型的第 3 层上运行，并使用 BGP 协议在其默认配置中的节点之间移动网络数据包，并使用 IP in IP 进行封装。**使用 BGP，Calico 可以本地定向数据包，而无需将它们包装在额外的封装层中。与更复杂的后端（如 VXLAN）相比，这种方法可以提高性能并简化网络问题的故障排除。

Calico 最有价值的特性是它对网络策略的支持。通过定义和执行网络策略，你可以规定哪些 pod 可以发送和接收流量并管理网络内的安全性。虽然 Calico 本身就是一个使用良好且功能强大的网络工具，但它的策略管理还允许它与 Flannel 或 Istio（一种流行的 Kubernetes 服务网格）等系统很好地配对。

Weave

Weave 或 Weave Net 是Weaveworks创建和支持的全功能 CNI 插件。Weave 在GitHub 存储库和Weaveworks网站上可用。与 Calico 一样，Weave 也提供带有支持计划的付费版本。

Weave 在 Kubernetes 集群的所有节点之间创建一个网格覆盖，并将其与每个节点上的路由组件结合使用，以在整个集群中动态路由流量。默认情况下，Weave 使用快速数据路径方法路由数据包，该方法尝试沿最短路径在节点之间发送流量。该网络不断分析交通流量并优化路线。如果快速数据路径发生故障，则称为***sleeve***数据包转发的较慢网络方法是备用方法。

Weave 包括创建和执行网络策略等功能，并允许你为整个网络配置加密。如果已配置，Weave 使用 NaCl 加密进行***sleeve流量，使用 IPsec ESP 加密进行***快速数据路径流量。

Cilium

Kubernetes CNI 插件领域的一个相对较新的人是Cilium。**Cilium 及其可观测性工具 Hubble 充分利用了eBPF。**eBPF 是一种在 Linux 内核中运行的新技术，可以配置和执行沙盒程序，无需更改内核源代码即可扩展内核的功能。Cilium 使用 eBPF 技术为你的 Kubernetes 集群网络支持更高级的网络和可观察性功能。

Cilium 提供的优于其他 CNI 插件的优势之一是在管理大型网络时减少了开销。虽然一些 CNI 插件依赖于每个 Kubernetes 集群节点上的iptables来管理网络寻址，但 Cilium 利用 eBPF 来更有效地处理这个问题并以更高性能的方式。当你的 Kubernetes 集群扩展到数万个节点时，高效的地址查找至关重要。

Cilium 提供在 OSI 网络模型的第 3、4 和 7 层运行的网络策略。这种在多个层应用策略的能力为你在 Kubernetes 集群中管理入口和出口流量的方式提供了更大的灵活性。虽然仍然是一个相对较新的 CNI 插件，但 Cilium 可能值得考虑，特别是如果你需要细粒度的安全控制或需要减少超大型 Kubernetes 集群的查找延迟。

为你的项目选择正确的解决方案

根据你的需要，选择要在集群中使用的正确 CNI 插件可能非常简单，也可能稍微复杂一些。如果你的唯一要求是基本的网络解决方案，那么 Flannel 可能是你的最佳选择。虽然它缺乏网络策略和加密等许多高级功能，但与其他 CNI 插件相比，它轻巧、快速且消耗的资源更少。

如果**通过网络策略和加密实现的性能和安全性至关重要，你应该考虑 Calico、Weave 或 Cilium 或像 Canal 这样的混合解决方案。**Canal 使用Calico和Flannel 的组合。Flannel 提供基本的网络连接，并与 Calico 一流的网络策略完美匹配。网络策略对于维护安全集群至关重要，尤其是考虑到网络攻击的风险增加。Calico 的文档包括关于采用零信任网络模型的必读部分。

**Cilium 可以为大规模部署提供优势，并利用 eBPF 来提高可观察性和网络管理效率。**Cilium 仍然是一个年轻的项目，在下面引用的基准测试中，它似乎确实更耗费资源。

说到基准测试，ITNEXT 每年都会发布CNI 插件的基准测试结果集。结果显示我们今天讨论的所有框架以及其他几个框架的性能相似。该研究使用默认配置在具有三个节点的集群上运行基准测试，并测量性能、吞吐量、延迟和资源使用情况等指标。

图 1 ITNEXT 的 CNI 插件基准比较

基准测试出色地突出了与 Kubernetes 集群的 CNI 插件相关的最关键因素。基准研究对所调查的每个工具都使用了默认配置。微调你的 CNI 插件可以提供更好的结果，并且可以满足你特定集群的需求。Platform9 的联合创始人兼产品副总裁 Madhura Maskasky 讨论了使用 Calico 实现高性能。

Kubernetes 最好的事情之一是不断增长的全球社区以及支持其增长的大量开源项目、服务提供商和托管平台。这对你来说意味着你并不孤单。许多工程师都面临着同样的问题和挑战。

链接：https://platform9.com/blog/the-ultimate-guide-to-using-calico-flannel-weave-and-cilium/

以上是关于使用 Cilium 增强 Kubernetes 网络安全的主要内容，如果未能解决你的问题，请参考以下文章

Cilium 多集群 ClusterMesh 介绍

使用CalicoFlannelWeave和Cilium的终极指南

kubernetes 集群中 cilium 的实践及其网络通信解析

关于centos8+kubeadm1.20.5+cilium+hubble的安装过程中cilium的配置问题--特别强调

seals部署kubernetes1.14.1

Cilium架构 (Cilium 2)