日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

TL;DR

通過網(wǎng)絡策略來提升網(wǎng)絡安全，可以極大降低了實現(xiàn)和維護的成本，同時對系統(tǒng)幾乎沒有影響。

目前創(chuàng)新互聯(lián)已為超過千家的企業(yè)提供了網(wǎng)站建設、域名、網(wǎng)站空間、網(wǎng)站托管、服務器托管、企業(yè)網(wǎng)站設計、鶴城網(wǎng)站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

尤其是基于 eBPF 技術(shù)的 Cilium，解決了內(nèi)核擴展性不足的問題，從內(nèi)核層面為工作負載提供安全可靠、可觀測的網(wǎng)絡連接。

背景

為什么說 Kubernetes 網(wǎng)絡存在安全隱患？集群中的 Pod 默認是未隔離的，也就是 Pod 之間的網(wǎng)絡是互通的，可以互相通信的。

這里就會有問題，比如由于數(shù)據(jù)敏感服務 B 只允許特定的服務 A 才能訪問，而服務 C 無法訪問 B。要禁止服務 C 對服務 B 的訪問，可以有幾種方案：

• 在 SDK 中提供通用的解決方案，實現(xiàn)白名單的功能。首先請求要帶有來源的標識，然后服務端可以接收規(guī)則設置放行特定標識的請求，拒絕其他的請求。
• 云原生的解決方案，使用服務網(wǎng)格的 RBAC、mTLS 功能。RBAC 實現(xiàn)原理與應用層的 SDK 方案類似，但是屬于基礎設施層的抽象通用方案；mTLS 則會更加復雜一些，在連接握手階段進行身份驗證，涉及證書的簽發(fā)、驗證等操作。

以上兩種方案各有利弊：

• SDK 的方案實現(xiàn)簡單，但是規(guī)模較大的系統(tǒng)會面臨升級推廣困難、多語言支持成本高等問題。
• 服務網(wǎng)格的方案是基礎設施層的通用方案，天生支持多語言。但是對于未落地網(wǎng)格的用戶來說，架構(gòu)變化大，成本高。如果單純?yōu)榱私鉀Q安全問題，使用網(wǎng)格方案性價比又很低，且不說現(xiàn)有網(wǎng)格實現(xiàn)等落地難度大及后期的使用維護成本高。

繼續(xù)向基礎設施下層找方案，從網(wǎng)絡層入手。Kubernetes 提供了的網(wǎng)絡策略 *NetworkPolicy*[1]，則可以實現(xiàn)“網(wǎng)絡層面的隔離”。

示例應用

在進一步演示 NetworkPolicy 的方案之前，先介紹用于演示的示例應用。我們使用 Cilium 在互動教程 Cilium getting started[2] 中使用的“星球大戰(zhàn)”場景。

這里有三個應用，星戰(zhàn)迷估計不會陌生：

• 死星 deathstar：在 80 端口提供 web 服務，有 2 個 副本，通過 Kubernetes Service 的負載均衡為帝國戰(zhàn)機對外提供”登陸“服務。
• 鈦戰(zhàn)機 tiefighter：執(zhí)行登陸請求。
• X翼戰(zhàn)機 xwing：執(zhí)行登陸請求。

如圖所示，我們使用了 Label 對三個應用進行了標識：org 和 class。在執(zhí)行網(wǎng)絡策略時，我們會使用這兩個標簽識別負載。

# 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 網(wǎng)絡策略

可以通過官方文檔[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 ：表示要應用網(wǎng)絡策略的工作負載均衡，通過 label 選擇到了 deathstar 的 2 個 Pod。
• policyTypes ：表示流量的類型，可以是 Ingress 或 Egress 或兩者兼具。這里使用 Ingress，表示對選擇的 deathstar Pod 的入站流量執(zhí)行規(guī)則。
• ingress.from：表示流量的來源工作負載，也是使用 podSelector 和 Label 進行選擇，這里選中了 org=empire 也就是所有“帝國的戰(zhàn)機”。
•  ingress.ports：表示流量的進入端口，這里列出了 deathstar 的服務端口。

接下來，我們測試下。

測試

先準備環(huán)境，我們使用 K3s[4] 作為 Kubernetes 環(huán)境。但由于 K3s 默認的 CNI 插件 Flannel 不支持網(wǎng)絡策略，我們需要換個插件，這里選擇 Calico[5]，即 K3s + Calico 的方案。

先創(chuàng)建一個單節(jié)點的集群：

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 狀態(tài)，因為還需要安裝 Calico：

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

待 Calico 成功運行后，所有的 Pod 也會成功運行。

接下來就是部署應用：

kubectl apply -f app.yaml

執(zhí)行策略前，執(zhí)行下面的命令看看“戰(zhàn)機能否登陸死星”：

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

從結(jié)果來看，兩種 ”戰(zhàn)機“（Pod 負載）都可以訪問 deathstar 服務。

此時執(zhí)行網(wǎng)絡策略：

kubectl apply -f native/networkpolicy.yaml

再次嘗試”登陸“，xwing 的登陸請求會停在那（需要使用 ctrl+c 退出，或者請求時加上 --connect-timeout 2）。

思考

使用 Kubernetes 網(wǎng)絡策略實現(xiàn)了我們想要的，從網(wǎng)絡層面為服務增加了白名單的功能，這種方案沒有改造成本，對系統(tǒng)也幾乎無影響。

Cilium 還沒出場就結(jié)束了？我們繼續(xù)看：

有時我們的服務會對外暴露一些管理端點，由系統(tǒng)調(diào)用執(zhí)行一些管理上的操作，比如熱更新、重啟等。這些端點是不允許普通服務來調(diào)用，否則會造成嚴重的后果。

比如示例中，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

出現(xiàn)了 Panic 錯誤，檢查 Pod 你會發(fā)現(xiàn) dealthstar 掛了。

Kubernetes 的網(wǎng)絡策略僅能工作在 L3/4 層，對 L7 層就無能為力了。

還是要請出 Cilium。

Cilium 網(wǎng)絡策略

由于 Cilium 涉及了 Linux 內(nèi)核、網(wǎng)絡等眾多知識點，要講清實現(xiàn)原理篇幅極大。故這里僅摘取了官網(wǎng)的介紹，后期希望有時間再寫一篇關(guān)于實現(xiàn)的。

Cilium 簡介

 Cilium[6] 是一個開源軟件，用于提供、保護和觀察容器工作負載（云原生）之間的網(wǎng)絡連接，由革命性的內(nèi)核技術(shù) eBPF[7] 推動。

eBPF 是什么？

 Linux 內(nèi)核一直是實現(xiàn)監(jiān)控/可觀測性、網(wǎng)絡和安全功能的理想地方。不過很多情況下這并非易事，因為這些工作需要修改內(nèi)核源碼或加載內(nèi)核模塊， 最終實現(xiàn)形式是在已有的層層抽象之上疊加新的抽象。eBPF 是一項革命性技術(shù)，它能在內(nèi)核中運行沙箱程序（sandbox programs）， 而無需修改內(nèi)核源碼或者加載內(nèi)核模塊。

將 Linux 內(nèi)核變成可編程之后，就能基于現(xiàn)有的（而非增加新的）抽象層來打造更加智能、 功能更加豐富的基礎設施軟件，而不會增加系統(tǒng)的復雜度，也不會犧牲執(zhí)行效率和安全性。

我們來看下 Cilium 的網(wǎng)絡策略：

# 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 的原生網(wǎng)絡策略差異不大，參考前面的介紹也都看懂，我們直接進入測試。

測試

由于 Cilium 本身就實現(xiàn)了 CNI，所以之前的集群就不能用了，先卸載集群：

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

還是使用同樣的命令創(chuàng)建單節(jié)點的集群：

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

待應用啟動后測試服務調(diào)用：

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

執(zhí)行 L4 網(wǎng)絡策略：

kubectl apply -f cilium/networkpolicy-L4.yaml

再次嘗試“登陸”死星，xwing 戰(zhàn)機同樣無法登陸，說明 L4 層的規(guī)則生效。

我們再嘗試 L7 層的規(guī)則：

# 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"

執(zhí)行規(guī)則：

kubectl apply -f cilium/networkpolicy-L7.yaml

這回，使用 tiefighter 調(diào)用死星的管理接口：

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 層的規(guī)則生效了。

分享題目：使用Cilium增強Kubernetes網(wǎng)絡安全
網(wǎng)頁網(wǎng)址：http://www.dlmjj.cn/article/djhhooe.html