写点什么

使用 Cilium 增强 Kubernetes 网络安全

作者:张晓辉
  • 2022 年 2 月 14 日
  • 本文字数:5098 字

    阅读完需:约 17 分钟

使用 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 对三个应用进行了标识:orgclass。在执行网络策略时,我们会使用这两个标签识别负载。


# app.yaml---apiVersion: v1kind: Servicemetadata:  name: deathstar  labels:    app.kubernetes.io/name: deathstarspec:  type: ClusterIP  ports:  - port: 80  selector:    org: empire    class: deathstar---apiVersion: apps/v1kind: Deploymentmetadata:  name: deathstar  labels:    app.kubernetes.io/name: deathstarspec:  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: v1kind: Podmetadata:  name: tiefighter  labels:    org: empire    class: tiefighter    app.kubernetes.io/name: tiefighterspec:  containers:  - name: spaceship    image: docker.io/tgraf/netperf---apiVersion: v1kind: Podmetadata:  name: xwing  labels:    app.kubernetes.io/name: xwing    org: alliance    class: xwingspec:  containers:  - name: spaceship    image: docker.io/tgraf/netperf
复制代码

Kubernetes 网络策略

可以通过官方文档获取更多详细信息,这里我们直接放出配置:


# native/networkpolicy.yamlapiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:  name: policy  namespace: defaultspec:  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 :表示流量的类型,可以是 IngressEgress 或两者兼具。这里使用 Ingress,表示对选择的 deathstar Pod 的入站流量执行规则。

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

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


接下来,我们测试下。

测试

先准备环境,我们使用 K3s 作为 Kubernetes 环境。但由于 K3s 默认的 CNI 插件 Flannel 不支持网络策略,我们需要换个插件,这里选择 Calico,即 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-landingShip landed
kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landingShip 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-portPanic: deathstar exploded
goroutine 1 [running]:main.HandleGarbage(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0xa) /code/src/github.com/empire/deathstar/ temp/main.go:9 +0x64main.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 是一个开源软件,用于提供、保护和观察容器工作负载(云原生)之间的网络连接,由革命性的内核技术 eBPF 推动。


eBPF 是什么?


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


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



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


# cilium/networkpolicy-L4.yamlapiVersion: "cilium.io/v2"kind: CiliumNetworkPolicymetadata:  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.sha256sumsudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/binrm cilium-linux-amd64.tar.gz{,.sha256sum}
cilium versioncilium-cli: v0.10.2 compiled with go1.17.6 on linux/amd64cilium image (default): v1.11.1cilium image (stable): v1.11.1cilium 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/1DaemonSet cilium Desired: 1, Ready: 1/1, Available: 1/1Containers: cilium Running: 1 cilium-operator Running: 1Cluster Pods: 3/3 managed by CiliumImage 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-landingShip landedkubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landingShip landed
复制代码


执行 L4 网络策略:


kubectl apply -f cilium/networkpolicy-L4.yaml
复制代码


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


我们再尝试 L7 层的规则:


# cilium/networkpolicy-L7.yamlapiVersion: "cilium.io/v2"kind: CiliumNetworkPolicymetadata:  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-portAccess denied# 登陆接口工作正常kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landingShip landed
复制代码


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



发布于: 刚刚阅读数: 2
用户头像

张晓辉

关注

大胆尝试,小心求证 2018.04.09 加入

胡说八道

评论

发布
暂无评论
使用 Cilium 增强 Kubernetes 网络安全