一、Network Policy 是什么,在云原生領(lǐng)域有和作用

Network Policy 是 Kubernetes 官方提出來的一種網(wǎng)絡(luò)策略的規(guī)范，用戶通過編寫符合對應(yīng)規(guī)范的規(guī)則來控制 k8s 集群內(nèi) L3 和 L4 層的網(wǎng)絡(luò)流量。

NetworkPolicy 主要的功能就是實(shí)現(xiàn)在云原生領(lǐng)域的容器網(wǎng)絡(luò)管控它給用戶提供了幾點(diǎn)最常用的能力

1. 容器網(wǎng)絡(luò)的出入網(wǎng)管控，最常用的就是控制業(yè)務(wù)的對公網(wǎng)訪問
2. 不同業(yè)務(wù)直接的網(wǎng)絡(luò)資源隔離，隨著集群規(guī)模的變大，不可避免的會(huì)存在多租戶的場景，不同租戶之間的網(wǎng)絡(luò)隔離 network policy 可以做到
3. 云原生領(lǐng)域的安全演練能力，例如模擬某些網(wǎng)絡(luò)異常，可以直接通過NetworkPolicy 功能實(shí)現(xiàn)

二、Network Policy 和容器網(wǎng)絡(luò)關(guān)系

云原生領(lǐng)域經(jīng)過多年的發(fā)展，上層的應(yīng)用各種服務(wù)層出不窮，作為云原生底層的基礎(chǔ)服務(wù)，容器網(wǎng)絡(luò)也面臨更多安全和網(wǎng)絡(luò)管控的需求。比如在大規(guī)模集群中不同業(yè)務(wù)希望互相禁止訪問，一些內(nèi)部服務(wù)希望禁止公網(wǎng)訪問或被公網(wǎng)訪問。kubernetes 對應(yīng)這些類似需求給出的解決方案就是 Network Policy 。Network Policy 的實(shí)現(xiàn)依賴于容器網(wǎng)絡(luò)，但是因?yàn)椴煌?CNI 技術(shù)方案和組網(wǎng)方式的不同，Network Policy 實(shí)現(xiàn)方式也是不同的，所以 kubernetes 官方只給出了一個(gè) Network Policy 的格式規(guī)范，并沒有給出具體的實(shí)現(xiàn)方案，示例如下：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: test-network-policynamespace: default
spec:podSelector:matchLabels:role: dbpolicyTypes:- Ingress- Egressingress:- from:- ipBlock:cidr: 172.17.0.0/16except:- 172.17.1.0/24- namespaceSelector:matchLabels:project: myproject- podSelector:matchLabels:role: frontendports:- protocol: TCPport: 6379egress:- to:- ipBlock:cidr: 10.0.0.0/24ports:- protocol: TCPport: 5978

三、Kubernetes 原生的Network Policy

kubernetes 原生的 Network Policy 功能相對簡單只支持 namespace 級別，功能且相對簡單，支持 L3 和 L4 基礎(chǔ)的網(wǎng)絡(luò)策略。

3.1 匹配規(guī)則

• Ingress ： 顧名思義，外部流量流入 Pod

ingress:-from:-ipBlock:
cidr: 172.17.0.0/16
except:- 172.17.1.0/24-namespaceSelector:
matchLabels:
project: myproject-podSelector:
matchLabels:
role: frontend
ports:-protocol: TCP
port: 6379

Ingress 通過 From 關(guān)鍵字來配置規(guī)則，可以通過ipBlock、namespaceSelector、podSelector、Ports 來選擇該策略所使用的對象。

podSelector：此選擇器將在與 NetworkPolicy 相同的 namespace 中選擇特定的 Pod，應(yīng)將其允許作為入站流量來源或出站流量目的地。

namespaceSelector：此選擇器將選擇特定的 namespace，應(yīng)將所有 Pod 用作其入站流量來源或出站流量目的地。

namespaceSelector 和 podSelector：一個(gè)指定 namespaceSelector 和 podSelector 的 to/from 條目選擇特定 namespace 中的特定 Pod。

• Egress： Pod 的出向流量

Egress 匹配策略和 ingress 基本一致，只是from 字段改為to

3.2 官方案例

1. 默認(rèn)拒絕所有的入站流量，在 default namespace 下生效

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: default-deny-ingress
spec:podSelector: {}policyTypes:- Ingress

1. 允許所有入站流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-all-ingress
spec:podSelector: {}ingress:- {}policyTypes:- Ingress

1. 默認(rèn)拒絕所有的出站流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: default-deny-egress
spec:podSelector: {}policyTypes:- Egress

1. 允許所有出站

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-all-egress
spec:podSelector: {}egress:- {}policyTypes:- Egress

1. 默認(rèn)拒絕所有的入站和出站流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: default-deny-all
spec:podSelector: {}policyTypes:- Ingress- Egress

四、開源組件拓展Network Policy

kubernetes 提供的原生的Network Policy 所能實(shí)現(xiàn)的功能相對較少，很難滿足日益復(fù)雜的容器網(wǎng)絡(luò)管控需求，所以各家CNI 基本上都有自己標(biāo)準(zhǔn)的Network Policy

4.1 Calico Network Policy

Calico 的Network Policy 相較于Kubernetes 原生的Network Policy 有兩點(diǎn)需要特別注意，第一個(gè)是增加了集群級別的網(wǎng)絡(luò)策略，第二個(gè)是對于流量的處理處理正常的allow 和 deny 還多了一個(gè)log 用來記錄被network policy 匹配到的流量 注：這里只介紹Calico 開源版本，企業(yè)版本的calico 不在本文的介紹范圍內(nèi)。

1. 集群級別的網(wǎng)絡(luò)策略 相較于k8s 原生的namespace 級別的網(wǎng)絡(luò)策略，集群級別網(wǎng)絡(luò)策略是一種非namespace 資源，可以應(yīng)用于獨(dú)立于命名空間的任何類型的端點(diǎn)（pod、VM、主機(jī)接口）。

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:name: allow-tcp-port-6379

1. 標(biāo)準(zhǔn)的Calico Network Policy 在以下示例中，傳入到應(yīng)用程序的 TCP 流量被拒絕，并且每個(gè)連接嘗試都記錄到系統(tǒng)日志中

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:name: allow-tcp-6379namespace: production
spec:selector: role == 'database'types:- Ingress- Egressingress:- action: Logprotocol: TCPsource:selector: role == 'frontend'- action: Denyprotocol: TCPsource:selector: role == 'frontend'

4.2 Cilium Network Policy

Cilium CNI 提供的Network Policy 的功能相對較多，它不僅支持3層、四層、7層，同時(shí)還支持通過自定義實(shí)體身份來選擇Network Policy 生效位置

4.2.1 三層Network Policy

****Cilium 的 Network Policy 支持多種模式，這里只選兩個(gè)經(jīng)典的來介紹

4.2.1.1 基于 ipBlock

此示例顯示所有含 app=myservice 的 Pod 訪問 20.1.1.1/32 和除了 10.96.0.0/12 所有 10.0.0.0/8 范圍的地址

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:name: "cidr-rule"
spec:endpointSelector:matchLabels:app: myServiceegress:- toCIDR:- 20.1.1.1/32- toCIDRSet:- cidr: 10.0.0.0/8except:- 10.96.0.0/12

4.2.1.2 基于 DNS 下面的示例表示，允許 default namespace 下標(biāo)簽為 app=test-app 的 pod 向 kube-system namespace 下標(biāo)簽為 k8s:k8s-app=kube-dns 的 pod 的 53 端口發(fā)送請求”my-remote-service.com“的域名解析請求

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:name: "to-fqdn"
spec:endpointSelector:matchLabels:app: test-appegress:- toEndpoints:- matchLabels:"k8s:io.kubernetes.pod.namespace": kube-system"k8s:k8s-app": kube-dnstoPorts:- ports:- port: "53"protocol: ANYrules:dns:- matchPattern: "*"- toFQDNs:- matchName: "my-remote-service.com"

4.2.2 四層的Cilium Network Policy

四層的網(wǎng)絡(luò)策略和 K8S 原生的規(guī)范除個(gè)別字段名稱之外基本一致，所以只給出一個(gè)基本的例子 以下規(guī)則限制所有具有app=myService標(biāo)簽的 pod 只能使用端口 80-444 上的 TCP 向任何第 3 層目的地發(fā)送數(shù)據(jù)包：

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:name: "l4-port-range-rule"
spec:endpointSelector:matchLabels:app: myServiceegress:- toPorts:- ports:- port: "80"endPort: 444protocol: TCP

4.2.3 七層的Cilium Network Policy

7層的Network Policy 目前支持的有 HTTP 協(xié)議，Kafka 相關(guān)以及DNS相關(guān)

// L7Rules is a union of port level rule types. Mixing of different port
// level rule types is disallowed, so exactly one of the following must be set.
// If none are specified, then no additional port level rules are applied.
type L7Rules struct {// HTTP specific rules.//// +optionalHTTP []PortRuleHTTP `json:"http,omitempty"`// Kafka-specific rules.//// +optionalKafka []PortRuleKafka `json:"kafka,omitempty"`// DNS-specific rules.//// +optionalDNS []PortRuleDNS `json:"dns,omitempty"`
}

4.2.3.1 HTTP 相關(guān)的L7 Network Policy

http 相關(guān)的NetworkPolicy 可以匹配path、method、host、headers 等信息，使用起來非常靈活

• 基于 url& path

下面的例子允許從帶有“env=prod”標(biāo)簽的 Pod 到帶有“app=service”標(biāo)簽的 Pod 的 GET 請求訪問 URL /public，但對其他任何 URL 或使用其他方法的請求將被拒絕。除端口 80 以外的其他端口上的請求將被丟

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:name: "rule1"
spec:description: "Allow HTTP GET /public from env=prod to app=service"endpointSelector:matchLabels:app: serviceingress:- fromEndpoints:- matchLabels:env: prodtoPorts:- ports:- port: "80"protocol: TCPrules:http:- method: "GET"path: "/public"

• 基于 path & method & header

下面的例子限制了所有帶有標(biāo)簽“app=myService”的 Pod 只能通過 TCP 協(xié)議接收端口 80 上的數(shù)據(jù)包。在使用這個(gè)端口進(jìn)行通信時(shí)，僅允許以下兩個(gè) API ：GET /path1 和 PUT /path2，并且必須在 HTTP 頭“X-My-Header”中設(shè)置值為 true。

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:name: "l7-rule"
spec:endpointSelector:matchLabels:app: myServiceingress:- toPorts:- ports:- port: '80'protocol: TCPrules:http:- method: GETpath: "/path1$"- method: PUTpath: "/path2$"headers:- 'X-My-Header: true'

4.2.3.2 KafKa相關(guān)的L7 Network Policy(beta) ? 允許使用“produce” role 創(chuàng)建 topic

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:name: "rule1"
spec:description: "enable empire-hq to produce to empire-announce and deathstar-plans"endpointSelector:matchLabels:app: kafkaingress:- fromEndpoints:- matchLabels:app: empire-hqtoPorts:- ports:- port: "9092"protocol: TCPrules:kafka:- role: "produce"topic: "deathstar-plans"- role: "produce"topic: "empire-announce"

? 允許使用 apiKeys 生成 topic

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:name: "rule1"
spec:description: "enable empire-hq to produce to empire-announce and deathstar-plans"endpointSelector:matchLabels:app: kafkaingress:- fromEndpoints:- matchLabels:app: empire-hqtoPorts:- ports:- port: "9092"protocol: TCPrules:kafka:- apiKey: "apiversions"- apiKey: "metadata"- apiKey: "produce"topic: "deathstar-plans"- apiKey: "produce"topic: "empire-announce"

4.2.3.3 DNS 相關(guān)的L7 Network Policy

下面的示例表示，允許 default namespace 下標(biāo)簽為 org=alliance 的 pod 向 kube-system namespace 下標(biāo)簽為 k8s:k8s-app=kube-dns 的 pod 的 53 端口發(fā)送請求”my-remote-service.com“的域名解析請求，允許的域名為 cilium.io *. cilium.io .api.cilium.io 同時(shí)允許 cilium.io sub.cilium.io service1.api.cilium.io specialservice.api.cilium.io 的外部請求

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:name: "tofqdn-dns-visibility"
spec:endpointSelector:matchLabels:any:org: allianceegress:- toEndpoints:- matchLabels:"k8s:io.kubernetes.pod.namespace": kube-system"k8s:k8s-app": kube-dnstoPorts:- ports:- port: "53"protocol: ANYrules:dns:- matchName: "cilium.io"- matchPattern: "*.cilium.io"- matchPattern: "*.api.cilium.io"- toFQDNs:- matchName: "cilium.io"- matchName: "sub.cilium.io"- matchName: "service1.api.cilium.io"- matchPattern: "special*service.api.cilium.io"toPorts:- ports:- port: "80"protocol: TCP

4.2.4 集群聯(lián)邦(Cluster Federation)的Cilium Network Policy

kubernetes 在 1.8 版本起就聲稱單個(gè)集群最多可支持 5000 個(gè) node 和 15 萬個(gè) Pod，但是實(shí)際上我們關(guān)注近幾年互聯(lián)網(wǎng)上因?yàn)榉?wù)崩潰而上的幾次熱搜就應(yīng)該明白，大規(guī)模集群一旦底層組件出現(xiàn)異常，帶來的影響是非常大的。這個(gè)時(shí)候我們就需要用到集群聯(lián)邦（Cluster Federation）。有了集群聯(lián)邦，同樣就需要考慮聯(lián)邦級別的 Network Policy ，恰巧 Cilium 就提供了對應(yīng)的這一能力。 以下策略說明如何允許特定 pod 在兩個(gè)集群之間進(jìn)行通信。

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:name: "allow-cross-cluster"
spec:description: "Allow x-wing in cluster1 to contact rebel-base in cluster2"endpointSelector:matchLabels:name: x-wingio.cilium.k8s.policy.cluster: cluster1egress:- toEndpoints:- matchLabels:name: rebel-baseio.cilium.k8s.policy.cluster: cluster2