[[436076]]

在你通過 Kubernetes 部署一個(gè)應(yīng)用之前，了解 Kubernetes 的網(wǎng)絡(luò)策略是一個(gè)基本的要求。

隨著越來越多的云原生應(yīng)用程序通過 Kubernetes 部署到生產(chǎn)環(huán)境，安全性是你必須在早期就需要考慮的一個(gè)重要檢查項(xiàng)。在設(shè)計(jì)云原生應(yīng)用程序時(shí)，預(yù)先嵌入安全策略非常重要。不這樣做會(huì)導(dǎo)致后續(xù)的安全問題，從而導(dǎo)致項(xiàng)目延遲，并最終給你帶來不必要的壓力和金錢投入。

這么多年來，人們總是把安全留到最后，直到他們的部署即將發(fā)布到生產(chǎn)環(huán)境時(shí)才考慮安全。這種做法會(huì)導(dǎo)致項(xiàng)目交付的延遲，因?yàn)槊總€(gè)組織都有要遵守的安全標(biāo)準(zhǔn)，這些規(guī)定被繞過或不遵守，并承受大量的風(fēng)險(xiǎn)才得以實(shí)現(xiàn)可交付成果。

對(duì)于剛開始學(xué)習(xí) Kubernetes 實(shí)施的人來說，理解 Kubernetes 網(wǎng)絡(luò)策略NetworkPolicy 可能會(huì)令人生畏。但這是在將應(yīng)用程序部署到 Kubernetes 集群之前必須了解的基本要求之一。在學(xué)習(xí) Kubernetes 和云原生應(yīng)用程序時(shí)，請(qǐng)把“不要把安全拋在腦后！”定為你的口號(hào)。

NetworkPolicy 概念

網(wǎng)絡(luò)策略NetworkPolicy 取代了你所知道的數(shù)據(jù)中心環(huán)境中的防火墻設(shè)備 —— 如吊艙Pod之于計(jì)算實(shí)例、網(wǎng)絡(luò)插件之于路由器和交換機(jī)，以及卷之于存儲(chǔ)區(qū)域網(wǎng)絡(luò)（SAN）。

默認(rèn)情況下，Kubernetes 網(wǎng)絡(luò)策略允許 吊艙Pod 從任何地方接收流量。如果你不擔(dān)心吊艙的安全性，那么這可能沒問題。但是，如果你正在運(yùn)行關(guān)鍵工作負(fù)載，則需要保護(hù)吊艙?？刂萍簝?nèi)的流量（包括入口和出口流量），可以通過網(wǎng)絡(luò)策略來實(shí)現(xiàn)。

要啟用網(wǎng)絡(luò)策略，你需要一個(gè)支持網(wǎng)絡(luò)策略的網(wǎng)絡(luò)插件。否則，你應(yīng)用的任何規(guī)則都將變得毫無用處。

Kubernetes.io 上列出了不同的網(wǎng)絡(luò)插件：

• CNI 插件：遵循 容器網(wǎng)絡(luò)接口Container Network Interface（CNI）規(guī)范，旨在實(shí)現(xiàn)互操作性。
  • Kubernetes 遵循 CNI 規(guī)范的 v0.4.0 版本。
• Kubernetes 插件：使用橋接器和主機(jī)本地 CNI 插件實(shí)現(xiàn)基本的 cbr0。

應(yīng)用網(wǎng)絡(luò)策略

要應(yīng)用網(wǎng)絡(luò)策略，你需要一個(gè)工作中的 Kubernetes 集群，并有支持網(wǎng)絡(luò)策略的網(wǎng)絡(luò)插件。

但首先，你需要了解如何在 Kubernetes 的環(huán)境使用網(wǎng)絡(luò)策略。Kubernetes 網(wǎng)絡(luò)策略允許 吊艙 從任何地方接收流量。這并不是理想情況。為了吊艙安全，你必須了解吊艙是可以在 Kubernetes 架構(gòu)內(nèi)進(jìn)行通信的端點(diǎn)。

1、使用 podSelector 進(jìn)行吊艙間的通信：

 - namespaceSelector:
    matchLabels:
      project: myproject 

2、使用 namespaceSelector 和/或 podSelector 和 namespaceSelector 的組合進(jìn)行命名空間之間的通信和命名空間到吊艙的通信。：

 - namespaceSelector:
    matchLabels:
      project: myproject
 - podSelector:
    matchLabels:
      role: frontend 

3、對(duì)于吊艙的 IP 塊通信，使用 ipBlock 定義哪些 IP CIDR 塊決定源和目的。

 - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24 

注意吊艙、命名空間和基于 IP 的策略之間的區(qū)別。對(duì)于基于吊艙和命名空間的網(wǎng)絡(luò)策略，使用選擇器來控制流量，而對(duì)基于 IP 的網(wǎng)絡(luò)策略，使用 IP 塊（CIDR 范圍）來定義控制。

把它們放在一起，一個(gè)網(wǎng)絡(luò)策略應(yīng)如下所示：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 192.168.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

參考上面的網(wǎng)絡(luò)策略，請(qǐng)注意 spec 部分。在此部分下，帶有標(biāo)簽 app=backend 的 podSelector 是我們的網(wǎng)絡(luò)策略的目標(biāo)。簡(jiǎn)而言之，網(wǎng)絡(luò)策略保護(hù)給定命名空間內(nèi)稱為 backend 的應(yīng)用程序。

此部分也有 policyTypes 定義。此字段指示給定策略是否適用于選定吊艙的入口流量、選定吊艙的出口流量，或兩者皆有。

spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress

現(xiàn)在，請(qǐng)看 Ingress（入口）和 Egress（出口）部分。該定義規(guī)定了網(wǎng)絡(luò)策略的控制。

首先，檢查 ingress from 部分。

此實(shí)例中，網(wǎng)絡(luò)策略允許從以下位置進(jìn)行吊艙連接：

• ipBlock
  • 允許 172.17.0.0/16
  • 拒絕 192.168.1.0/24
• namespaceSelector
  • myproject: 允許來自此命名空間并具有相同標(biāo)簽 project=myproject 的所有吊艙。
• podSelector
  • frontend: 允許與標(biāo)簽 role=frontend 匹配的吊艙。

ingress:
 - from:
  - ipBlock:
      cidr: 172.17.0.0/16
      except:
      - 192.168.1.0/24
  - namespaceSelector:
      matchLabels:
        project: myproject
  - podSelector:
      matchLabels:
        role: frontend
 

現(xiàn)在，檢查 egress to 部分。這決定了從吊艙出去的連接：

• ipBlock
  • 10.0.0.0/24: 允許連接到此 CIDR
  • Ports: 允許使用 TCP 和端口 5978 進(jìn)行連接

egress:
 - to:
  - ipBlock:
      cidr: 10.0.0.0/24
  ports:
  - protocol: TCP
    port: 5978
 

網(wǎng)絡(luò)策略的限制

僅靠網(wǎng)絡(luò)策略無法完全保護(hù)你的 Kubernetes 集群。你可以使用操作系統(tǒng)組件或 7 層網(wǎng)絡(luò)技術(shù)來克服已知限制。你需要記住，網(wǎng)絡(luò)策略只能解決 IP 地址和端口級(jí)別的安全問題 —— 即開放系統(tǒng)互聯(lián)（OSI）中的第 3 層或第 4 層。

為了解決網(wǎng)絡(luò)策略無法處理的安全要求，你需要使用其它安全解決方案。以下是你需要知道的一些 用例，在這些用例中，網(wǎng)絡(luò)策略需要其他技術(shù)的增強(qiáng)。

總結(jié)

了解 Kubernetes 的網(wǎng)絡(luò)策略很重要，因?yàn)樗菍?shí)現(xiàn)（但不是替代）你通常在數(shù)據(jù)中心設(shè)置中使用的防火墻角色的一種方式，但適用于 Kubernetes。將此視為容器安全的第一層，僅僅依靠網(wǎng)絡(luò)策略并不是一個(gè)完整的安全解決方案。

網(wǎng)絡(luò)策略使用選擇器和標(biāo)簽在吊艙和命名空間上實(shí)現(xiàn)安全性。此外，網(wǎng)絡(luò)策略還可以通過 IP 范圍實(shí)施安全性。

充分理解網(wǎng)絡(luò)策略是在 Kubernetes 環(huán)境中安全采用容器化的一項(xiàng)重要技能。