Kubernetes網絡策略，這一篇就夠了

目前許多組織都在採用Kubernetes來運行他們的應用程序。以至於有些人將Kubernetes稱爲新的數據中心操作系統。因此，組織開始將Kubernetes(通常縮寫爲k8s)視爲關鍵任務平臺，它需要包括網絡安全在內的成熟業務流程。

負責保護這個新平臺的網絡安全團隊可能發現它出奇的不同。例如，默認的Kubernetes策略是允許任何連接。

本文提供了一些關於Kubernetes網絡策略工作原理的簡介，它們如何與傳統防火牆策略進行比較以及一些可以幫助你保護Kubernetes應用程序的陷阱和最佳實踐。

Kubernetes網絡策略

Kubernetes提供了一種稱爲網絡策略的機制，可用於對部署在平臺上的應用程序實施第3層分隔。網絡策略缺乏現代防火牆的高級功能，如第7層控制和威脅檢測，但是它們確實提供了基本的網絡安全，這是一個很好的起點。

網絡策略控制Pod的通信

Kubernetes的工作負載在pod中運行，pod由一個或多個部署在一起的容器組成。Kubernetes爲每個pod分配一個IP地址，這個地址可以從其他所有pod路由，甚至可以跨底層服務器。Kubernets網絡策略指定pod組的訪問權限，類似於雲服務中的安全組用於控制對虛擬機實例的訪問。

編寫網絡策略

與其他Kubernetes資源一樣，網絡策略可以使用一種稱爲YAML的語言定義。下面是一個簡單的例子，它允許從負載均衡到postgres的訪問。

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.postgres 
5.   namespace: default 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: postgres 
10.   ingress: 
11.   - from: 
12.     - podSelector: 
13.         matchLabels: 
14.           app: balance 
15.   policyTypes: 
16.   - Ingress 

 爲了編寫你自己的網絡策略，你需要對yaml有基本的瞭解。Yaml基於縮進(使用的是空格，而不是tab)。縮進項屬於其上方最接近的縮進項。連字符(破折號)開始一個新的列表項。所有其他項都是映射條目。你可以在網上找到大量關於yaml的信息。

編寫完策略的YAML文件後，使用kubectl創建策略：

1. kubectl create -f policy.yaml 

網絡策略定義

網絡策略定義由四個元素組成：

podSelector：將受此策略約束的pod(策略目標)。必填

policyType：指定哪些類型的策略包含在這個策略中，ingress或egress。該項是可選的，但建議總是明確的指定它。可選

ingress：允許傳入目標pod的流量。可選

egress：允許從目標pod傳出的流量。可選

下面這個例子是從Kubernetes官網上改編的(將“role”改爲了“app”)，它指定了四個元素：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: test-network-policy 
5.   namespace: default 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: db 
10.   policyTypes: 
11.   - Ingress 
12.   - Egress 
13.   ingress: 
14.   - from: 
15.     - ipBlock: 
16.         cidr: 172.17.0.0/16 
17.         except: 
18.         - 172.17.1.0/24 
19.     - namespaceSelector: 
20.         matchLabels: 
21.           project: myproject 
22.     - podSelector: 
23.         matchLabels: 
24.           role: frontend 
25.     ports: 
26.     - protocol: TCP 
27.       port: 6379 
28.   egress: 
29.   - to: 
30.     - ipBlock: 
31.         cidr: 10.0.0.0/24 
32.     ports: 
33.     - protocol: TCP 
34.       port: 5978 

 

注意，你不必包含所有四個元素。podSelector是必填的，其餘三個是可選的。

如果你忽略了policyType，則推斷如下：

• 策略總是被認爲指定了一個ingress定義。如果你沒有明確的定義它，它將被視爲“不允許流量“。
• egress將由是否存在egress元素誘導。

爲了避免錯誤，建議總是顯式的指定policyType。

如果沒有提供ingress或egress的定義，並且根據上面的邏輯假定它們存在，策略將認爲它們是“不允許流量”。

默認策略是允許

當沒有定義任何策略時，Kubernetes允許所有通信。所有pod都可以相互自由通信。從安全角度來看，這聽起來可能有悖常理，但請記住，Kubernetes是由希望應用程序進行通信的開發人員設計的。網絡策略是作爲後來的增強功能添加的。

命名空間

命名空間是Kubernetes的多租戶機制，旨在將命名空間環境相互隔離，但是，命名空間的通信在默認情況下仍然是被允許的。

與大多數Kubernetes實體一樣，網絡策略也位於特定的命名空間中。元數據頭部告訴Kubernetes策略屬於哪個命名空間：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: test-network-policy 
5.   namespace: my-namespace 
6. spec: 
7. ... 

如果你沒有明確指定元數據的命名空間，它將應用於kubectl提供的命名空間(默認是namespace=default)。

1. kubectl apply -n my-namespace -f namespace.yaml 

建議顯式指定命名空間，除非你正在編寫的策略要統一應用在多個命名空間中。

策略中的podSelector元素將從策略所屬的命名空間中選擇pod(它不能從另一個命名空間選擇pod)。

ingress和egress元素中的podSelector也會選擇相同命名空間中的pod,除非你將它們和namespaceSelector一起使用。

策略命名約定

策略的名稱在命名空間中是唯一的。一個命名空間中不能有兩個同名的策略，但是不同的命名空間可以有同名的策略。當你想要在多個命名空間重複應用某個策略時，這非常方便。

我喜歡的策略命名方法之一是將命名空間與pod組合起來，例如：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.postgres 
5.   namespace: default 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: postgres 
10.   ingress: 
11.   - from: 
12.     - podSelector: 
13.         matchLabels: 
14.           app: admin 
15.   policyTypes: 
16.   - Ingress 

標籤

Kubernetes對象，如pod和namespace，可以附加用戶自定義標籤。Kubernetes網絡策略依賴於標籤來選擇它們應用於的pod：

1. podSelector: 
2.   matchLabels: 
3.     role: db 

或者它們應用於的命名空間。下面的例子中選擇匹配標籤的命名空間中的所有pod：

1. namespaceSelector: 
2.   matchLabels: 
3.     project: myproject 

需要注意的一點是：如果你使用namespaceSelector，請確保所選擇的命名空間確實具有所使用的標籤。請記住，像default和kube-system這樣的內置命名空間沒有現成的標籤。你可以像這樣給命名空間添加一個標籤：

1. kubectl label namespace default namespace=default 

元數據中的namespace是命名空間的實際名稱，而不是標籤：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: test-network-policy 
5.   namespace: default 
6. spec: 
7. ... 

源和終點

防火牆策略由具有源和終點的規則組成。Kubernetes網絡策略是爲目標(應用策略的一組pod)定義的，然後爲目標指定傳入或傳出流量。再次使用相同的例子，你可以看到策略目標——默認命名空間中所有具有標籤爲“db:app”的pod:

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: test-network-policy 
5.   namespace: default 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: db 
10.   policyTypes: 
11.   - Ingress 
12.   - Egress 
13.   ingress: 
14.   - from: 
15.     - ipBlock: 
16.         cidr: 172.17.0.0/16 
17.         except: 
18.         - 172.17.1.0/24 
19.     - namespaceSelector: 
20.         matchLabels: 
21.           project: myproject 
22.     - podSelector: 
23.         matchLabels: 
24.           role: frontend 
25.     ports: 
26.     - protocol: TCP 
27.       port: 6379 
28.   egress: 
29.   - to: 
30.     - ipBlock: 
31.         cidr: 10.0.0.0/24 
32.     ports: 
33.     - protocol: TCP 
34.       port: 5978 

 

該策略中的ingress項允許到目標pod的傳入流量。因此，ingress被解釋爲“源”，目標被解釋爲各自的“終點”。同樣，egress被解釋爲“終點”，目標是各自的“源”。

Egress和DNS

當執行egress時，必須小心不要阻止DNS，Kubernetes使用DNS將service的名稱解釋爲其IP地址。否則，這個策略將不起作用，因爲你沒有允許balance執行DNS查找：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.balance 
5.   namespace: default 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: balance 
10.   egress: 
11.   - to: 
12.     - podSelector: 
13.         matchLabels: 
14.           app: postgres 
15.   policyTypes: 
16.   - Egress 

 

要解決它，你必須允許訪問DNS服務：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.balance 
5.   namespace: default 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: balance 
10.   egress: 
11.   - to: 
12.     - podSelector: 
13.         matchLabels: 
14.           app: postgres 
15.   - to: 
16.     ports: 
17.     - protocol: UDP 
18.       port: 53 
19.   policyTypes: 
20.   - Egress 

“to”元素爲空，它隱式選擇了所有命名空間中的所有pod，從而允許balance通過Kubernetes的DNS服務執行DNS查找，DNS服務通常位於kube-system命名空間中。

雖然這是有效的，但它過於寬鬆和不安全——它允許在集羣外部進行DNS查找。

你可以分階段鎖定它：

1.通過添加一個namespaceSelector只允許在集羣內進行DNS查找：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.balance 
5.   namespace: default 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: balance 
10.   egress: 
11.   - to: 
12.     - podSelector: 
13.         matchLabels: 
14.           app: postgres 
15.   - to: 
16.     - namespaceSelector: {} 
17.     ports: 
18.     - protocol: UDP 
19.       port: 53 
20.   policyTypes: 
21.   - Egress 

 

2.只允許DNS在kube-system命名空間中

爲此，你需要爲kube-system命名空間添加一個標籤：

1. kubectl label namespace kube-system namespace=kube-system 

然後用namespaceSelector在策略中指定它：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.balance 
5.   namespace: default 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: balance 
10.   egress: 
11.   - to: 
12.     - podSelector: 
13.         matchLabels: 
14.           app: postgres 
15.   - to: 
16.     - namespaceSelector: 
17.         matchLabels: 
18.           namespace: kube-system 
19.     ports: 
20.     - protocol: UDP 
21.       port: 53 
22.   policyTypes: 
23.   - Egress 

3.偏執狂可能想更進一步，將DNS限制爲kube-system命名空間中特定的DNS服務。請參考下面的“通過命名空間和pod過濾”章節。

另一種選擇是在命名空間級別允許DNS，這樣就不需要爲每個服務指定它了：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.dns 
5.   namespace: default 
6. spec: 
7.   podSelector: {} 
8.   egress: 
9.   - to: 
10.     - namespaceSelector: {} 
11.     ports: 
12.     - protocol: UDP 
13.       port: 53 
14.   policyTypes: 
15.   - Egress 

空的podSelector選擇該命名空間中的所有pod。

第一個匹配和規則順序

防火牆管理員知道對數據包採取的操作(允許或拒絕)由與其匹配的第一個規則決定。但是在Kubernetes中，策略的順序並不重要。默認的行爲是，當沒有定義策略時，允許所有通信，因此所有pod之間可以彼此通信。一旦定義了策略，每個至少被一個策略選擇的pod，將根據選擇它的策略的並集(邏輯或)進行隔離：

沒有被任何策略選中的pod繼續保持開放。你可以通過定義cleanup規則來改變這個行爲。

Cleanup規則(拒絕)

防火牆策略通常通過any-any-any-deny規則來丟棄所有非顯式允許的流量。Kubernetes沒有拒絕操作，但是你可以使用一個常規的規則來實現相同的效果，該策略指定policyTypes=Ingress，但是省略了實際ingress的定義，這被解釋爲“不允許進入”。

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: deny-all 
5.   namespace: default 
6. spec: 
7.   podSelector: {} 
8.   policyTypes: 
9.   - Ingress 

 

該策略選擇命名空間中的所有pod作爲源，未定義ingress——這意味着不允許流量進入。

類似的，你可以拒絕來自一個命名空間的所有出站流量：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: deny-all-egress 
5.   namespace: default 
6. spec: 
7.   podSelector: {} 
8.   policyTypes: 
9.   - Egress 

 

請記住，任何其他允許訪問命名空間中pod的策略都將優先於此拒絕策略——相當於防火牆中將允許策略添加到拒絕策略之上。

Any-Any-Any-Allow

通過使用一個空的ingress元素修改上面的deny-all策略，可以創建一個allow-all策略：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: allow-all 
5.   namespace: default 
6. spec: 
7.   podSelector: {} 
8.   ingress:  
9.   - {} 
10.   policyTypes: 
11.   - Ingress 

這允許所有命名空間中的所有pod(和IP)到默認命名空間中的任何pod的通信。這是默認行爲，因此通常不需要這麼做。但是，爲了查找問題，暫時覆蓋所有其他規則可能很有用。

你可以縮小此範圍，僅允許訪問默認命名空間中的一組特定的pod：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: allow-all-to-balance 
5.   namespace: default 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: balance 
10.   ingress:  
11.   - {} 
12.   policyTypes: 
13.   - Ingress 

 

下面的策略允許任何入站和出站流量(包括訪問集羣外的任何IP)：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: allow-all 
5. spec: 
6.   podSelector: {} 
7.   ingress: 
8.   - {} 
9.   egress: 
10.   - {} 
11.   policyTypes: 
12.   - Ingress 
13.   - Egress 

組合多個策略

策略在三個級別上使用邏輯或進行組合。每個pod根據應用於它的所有策略的並集決定是否允許通信。

1.在“from”和“to”項中，你可以定義三種類型的項，他們通過“或”進行組合：

• namespaceSelector——選擇一整個命名空間
• podSelector——選擇pod
• ipBlock——選擇一個子網

你可以在from/to下定義任意數量的項(即使是相同類型也可以定義多條)，它們將通過邏輯或組合在一起：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.postgres 
5.   namespace: default 
6. spec: 
7.   ingress: 
8.   - from: 
9.     - podSelector: 
10.         matchLabels: 
11.           app: indexer 
12.     - podSelector: 
13.         matchLabels: 
14.           app: admin 
15.   podSelector: 
16.     matchLabels: 
17.       app: postgres 
18.   policyTypes: 
19.   - Ingress 

2.在一個策略中，ingress策略可以有多個“from”項，它們通過邏輯或組合在一起。同樣，egress策略可以有多個“to”項，它們也通過邏輯或組合在一起：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.postgres 
5.   namespace: default 
6. spec: 
7.   ingress: 
8.   - from: 
9.     - podSelector: 
10.         matchLabels: 
11.           app: indexer 
12.   - from: 
13.     - podSelector: 
14.         matchLabels: 
15.           app: admin 
16.   podSelector: 
17.     matchLabels: 
18.       app: postgres 
19.   policyTypes: 
20.   - Ingress 

3.多個策略也通過邏輯或組合在一起。

但是當組合策略時，這裏有一些限制:Kubernetes只能組合policyType(ingress或egress)不同的策略，多個策略都指定ingress(或egress)將會互相覆蓋。

命名空間之間的通信

默認情況下，命名空間間的通信是允許的。你可以使用deny-all策略來改變它，以阻止從或者到該命名空間的通信。

如果你阻止了對某個命名空間的訪問，可以使用namespaceSelector允許來自一個特定的命名空間的訪問。

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: database.postgres 
5.   namespace: database 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: postgres 
10.   ingress: 
11.   - from: 
12.     - namespaceSelector: 
13.         matchLabels: 
14.           namespace: default 
15.   policyTypes: 
16.   - Ingress 

 

這允許default命名空間中的所有pod訪問database命名空間中的postgres pod。但是，如果只想允許default命名空間中特定的pod訪問postgres該怎麼辦呢?

通過namespace和pod聯合過濾

Kubernetes 1.11及以上允許你將namespaceSelector和podSelector通過邏輯與組合在一起：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: database.postgres 
5.   namespace: database 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: postgres 
10.   ingress: 
11.   - from: 
12.     - namespaceSelector: 
13.         matchLabels: 
14.           namespace: default 
15.       podSelector: 
16.         matchLabels: 
17.           app: admin 
18.   policyTypes: 
19.   - Ingress 

爲什麼這被解釋爲“與”，而不是“或”呢?

請注意，podSelector不是以破折號開頭的，在yaml中這意味着，podSelector與前面的namespaceSelector屬於同一個列表項，因此它們通過邏輯與進行組合。如果你在podSelector前面添加一個破折號，將創建一個新的列表項，這將與前面的namespaceSelector通過邏輯或組合。要在所有命名空間中選擇具有特定標籤的pod，可以指定一個空的namespaceSelector：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: database.postgres 
5.   namespace: database 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: postgres 
10.   ingress: 
11.   - from: 
12.     - namespaceSelector: {} 
13.       podSelector: 
14.         matchLabels: 
15.           app: admin 
16.   policyTypes: 
17.   - Ingress 

多個標籤通過邏輯與組合

具有多個對象(主機、網絡、組...)的防火牆規則被解釋爲邏輯或。例如，如果數據包的源匹配HOST_1或HOST_2，則應用此規則：

與之相反的是，在Kubernetes中，podSelector和namespaceSelector中的多個標籤通過邏輯與進行組合。例如，這將選擇同時具有標籤role=db和version=v2的pod：

1. podSelector: 
2.   matchLabels: 
3.     role: db 
4.     version: v2 

相同的邏輯適用所有類型的選擇器：策略目標的選擇器、pod的選擇器、命名空間的選擇器。

子網和IP地址(ipBlock)

防火牆使用vlan、ip和子網來分割網絡。在Kubernetes中，pod的IP是自動分配的，並且可能經常變動，因此網絡策略使用標籤來選擇pod和命名空間。子網(ipBlock)用於ingress或egress連接(南北向)。例如，下面這個策略允許default命名空間中的所有pod訪問谷歌的DNS服務：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: egress-dns 
5.   namespace: default 
6. spec: 
7.   podSelector: {} 
8.   policyTypes: 
9.   - Egress 
10.   egress: 
11.   - to: 
12.     - ipBlock: 
13.         cidr: 8.8.8.8/32 
14.     ports: 
15.     - protocol: UDP 
16.       port: 53 

本例中空的podSelector表示“選擇該命名空間中的所有pod”。該策略只允許訪問8.8.8.8，這意味着它拒絕訪問其他任何IP。因此，實際上，你已經阻止了對Kubernetes內部DNS服務的訪問。如果你仍然想允許它，需要顯式的指定它。

通常ipBlock和podSelector是互斥的，因爲通常你在ipBlock中不使用內部pod IP。如果你使用內部pod IP指定ipBlock，它實際上將允許與具有這些ip的pod進行通信。但是在實踐中並不知道該用哪些IP，這就是爲什麼不應該用IP來選擇pod。

下面這個策略中包含所有IP，並允許訪問所有其它pod：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: egress-any 
5.   namespace: default 
6. spec: 
7.   podSelector: {} 
8.   policyTypes: 
9.   - Egress 
10.   egress: 
11.   - to: 
12.     - ipBlock: 
13.         cidr: 0.0.0.0/0 

你可以通過排除內部IP來只允許訪問外部IP。例如，如果pod的子網是10.16.0.0/14：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: egress-any 
5.   namespace: default 
6. spec: 
7.   podSelector: {} 
8.   policyTypes: 
9.   - Egress 
10.   egress: 
11.   - to: 
12.     - ipBlock: 
13.         cidr: 0.0.0.0/0 
14.         except: 
15.         - 10.16.0.0/14 

 

端口和協議

pod通常只監聽一個端口，這意味着你可以簡單的在策略中省略端口，默認允許任何端口。但是最好將策略設置爲受限的，顯式的指定端口：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.postgres 
5.   namespace: default 
6. spec: 
7.   ingress: 
8.   - from: 
9.     - podSelector: 
10.         matchLabels: 
11.           app: indexer 
12.     - podSelector: 
13.         matchLabels: 
14.           app: admin 
15.     ports: 
16.       - port: 443 
17.         protocol: TCP 
18.       - port: 80 
19.         protocol: TCP 
20.   podSelector: 
21.     matchLabels: 
22.       app: postgres 
23.   policyTypes: 
24.   - Ingress 

請注意，端口應用於它們所在的“to”或“from”子句中的所有項。如果你想爲不同的項指定不同的端口，你可以將ingress或egress拆分爲多個“to”或“from”，每個都有自己的端口：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.postgres 
5.   namespace: default 
6. spec: 
7.   ingress: 
8.   - from: 
9.     - podSelector: 
10.         matchLabels: 
11.           app: indexer 
12.     ports: 
13.      - port: 443 
14.        protocol: TCP 
15.   - from: 
16.     - podSelector: 
17.         matchLabels: 
18.           app: admin 
19.     ports: 
20.      - port: 80 
21.        protocol: TCP 
22.   podSelector: 
23.     matchLabels: 
24.       app: postgres 
25.   policyTypes: 
26.   - Ingress 

 

端口的默認行爲：

• 如果完全省略端口，則表示所有端口和所有協議
• 如果省略協議，則默認爲TCP
• 如果省略端口，則默認爲所有端口

最佳實踐：不要依賴默認行爲，顯式的指明。

注意你必須使用pod的端口，而不是service的端口。

策略是爲pod定義的還是爲service定義的?

當一個pod訪問Kubernetes中另一個pod時，它通常要通過service，service是一個虛擬的負載均衡器，它將流量轉發到實現該服務的pod上。你可能會以爲網絡策略是控制對service的訪問的，但事實並非如此。Kubernetes網絡策略是應用於pod的端口，而非service的端口。

例如，如果一個service監聽80端口，但是它將流量轉發到監聽8080端口的pod上，你需要在網絡策略中指定8080端口。

這種設計不是最優的，因爲當有人更改服務的內部工作方式時(如pod正在監聽的端口)，你需要更新網絡策略。

顯然，有一種解決方案可以解決這個問題，即使用命名端口，而不是硬編碼的數字端口：

1. apiVersion: networking.k8s.io/v1 
2. kind: NetworkPolicy 
3. metadata: 
4.   name: default.allow-hello 
5.   namespace: default 
6. spec: 
7.   podSelector: 
8.     matchLabels: 
9.       app: hello 
10.   policyTypes: 
11.   - Ingress 
12.   ingress: 
13.   - from: 
14.     - podSelector: 
15.         matchLabels: 
16.           run: curl 
17.     ports: 
18.     - port: my-http 

你需要在pod的定義中指定這個端口的名字：

1. apiVersion: extensions/v1beta1 
2. kind: Deployment 
3. metadata: 
4.   labels: 
5.     app: hello 
6.   name: hello 
7. spec: 
8.   selector: 
9.     matchLabels: 
10.       app: hello 
11.   template: 
12.     metadata: 
13.       labels: 
14.         app: hello 
15.     spec: 
16.       containers: 
17.       - image: gcr.io/hello-minikube-zero-install/hello-node 
18.         imagePullPolicy: Always 
19.         name: hello-node 
20.         ports: 
21.         - containerPort: 8080 
22.           name: my-http 

這樣就將網絡策略和pod解耦了。

Ingress

術語“ingress”在Kubernetes中有兩種含義：

1. ingress網絡策略允許你控制其他pod或外部IP對pod的訪問
2. Kubergess的ingress是一種配置外部負載均衡器路由流量到集羣內部的方式

你可以編寫一個k8s網絡策略限制來自Kubernetes ingress的訪問，但在大多數情況下這不是很有用，因爲它只控制負載均衡器的內部IP。爲了控制可以訪問集羣的外部子網，你需要在外部實施點(如負載均衡本身或負載均衡前面的防火牆)配置訪問控制。

需要同時定義ingress和egress麼?

簡單的回答是肯定的——爲了允許pod A訪問pod B，你需要允許pod A通過egress策略創建出站連接，並允許pod B通過ingress策略接受入站連接。

然而，實際上，你可能對兩個方向中的一個使用默認的允許策略。

如果源pod被一個或多個egress策略選中，則將根據策略聯合對其進行限制，在這種情況下你需要明確允許它連接到目標pod。如果pod不被任何策略選中，則它默認允許所有的出站流量。

同樣，被一個或多個ingress策略選中的目標pod，也會受到策略的聯合限制，在這種情況下你必須明確允許它接受來自源pod的流量。如果pod沒有被任何策略選中，則它默認允許所有入站流量。

hostNetwork陷阱

Kubernetes通常在自己的隔離網絡中運行pod，然而，你可以指定Kubernetes在主機上運行pod：

1. hostNetwork: true 

這樣會完全繞開網路策略，pod像主機上運行的其他任何進程一樣進行通信。

流量日誌

Kubernetes網絡策略不能生成流量日誌。這很難知道策略是不是像預期一樣工作。這也是安全分析方面的主要限制。

控制到外部服務的流量

Kubernetes網絡策略不允許你爲egress指定完全限定的域名(DNS)。當試圖控制到無固定IP的外部站點(如aws.com)的流量時，這是一個限制。

策略驗證

防火牆將警告甚至拒絕接受無效的策略。Kubernetes也做了一些驗證。當使用kubectl定義網絡策略時，Kubernetes可能會告訴你策略無效並且拒絕接受。在其它情況下，Kubernetes將接受策略並修改它缺失的細節，你可以通過以下命令查看它：

kubernetes get networkpolicy  -o yaml

請注意，Kubernetes的驗證不是無懈可擊的，它可能允許策略中出現某些類型的錯誤。

執行

Kubernetes本身並不執行網絡策略，它只是一個API網關，它將執行的艱鉅工作傳遞給一個稱爲容器網絡接口(CNI)的底層系統。在沒有合適CNI的Kubernetes集羣中定義策略就像在沒有安裝防火牆的服務器上定義防火牆規則一樣。你必須確保擁有具有安全功能的CNI，或者，對於託管的Kubernetes平臺，你需要顯式的啓用將爲你安裝CNI的網絡策略。

請注意，如果CNI不支持，你定義了一個網絡策略，Kubernetes不會向你告警。

有狀態還是無狀態?

目前所有的Kubernetes CNI都是有狀態的，這使得pod能在它發起的TCP連接上接收應答，而不必爲應答打開高端口。我不知道有沒有Kubernetes標準保證狀態性。

高級安全策略管理

以下是一些針對Kubernetes實施更高級的網絡策略的方法：

1. 服務網格設計模式使用sidecar在服務級別提供更高級的遙測和流量控制。有關示例，請參考Istio。
2. 一些CNI提供商已經將他們的工具擴展到了Kubernetes網絡策略之外。
3. Tufin Orca——用於實現Kubernetes網絡策略的可視化和自動化。

總結

Kubernetes網絡策略爲集羣劃分提供了一種很好的方法，但是它們不直觀並且有許多注意的地方。我相信，由於這種複雜性，一定有許多集羣在他們的策略中存在“bug”。可能的解決方案是自動化策略定義或其他分割方法。同時，希望本文對澄清和解決你可能遇到的問題有所幫助。