使用 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，则可以实现“网络层面的隔离”。

示例应用

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

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

• 死星 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.kuber