Kubernetes 網(wǎng)絡(luò)策略基礎(chǔ)
在你通過 Kubernetes 部署一個應(yīng)用之前,了解 Kubernetes 的網(wǎng)絡(luò)策略是一個基本的要求。
隨著越來越多的云原生應(yīng)用程序通過 Kubernetes 部署到生產(chǎn)環(huán)境,安全性是你必須在早期就需要考慮的一個重要檢查項。在設(shè)計云原生應(yīng)用程序時,預(yù)先嵌入安全策略非常重要。不這樣做會導(dǎo)致后續(xù)的安全問題,從而導(dǎo)致項目延遲,并最終給你帶來不必要的壓力和金錢投入。
這么多年來,人們總是把安全留到最后,直到他們的部署即將發(fā)布到生產(chǎn)環(huán)境時才考慮安全。這種做法會導(dǎo)致項目交付的延遲,因為每個組織都有要遵守的安全標準,這些規(guī)定被繞過或不遵守,并承受大量的風(fēng)險才得以實現(xiàn)可交付成果。
對于剛開始學(xué)習(xí) Kubernetes 實施的人來說,理解 Kubernetes 網(wǎng)絡(luò)策略 可能會令人生畏。但這是在將應(yīng)用程序部署到 Kubernetes 集群之前必須了解的基本要求之一。在學(xué)習(xí) Kubernetes 和云原生應(yīng)用程序時,請把“不要把安全拋在腦后!”定為你的口號。
NetworkPolicy 概念
網(wǎng)絡(luò)策略 取代了你所知道的數(shù)據(jù)中心環(huán)境中的防火墻設(shè)備 —— 如吊艙之于計算實例、網(wǎng)絡(luò)插件之于路由器和交換機,以及卷之于存儲區(qū)域網(wǎng)絡(luò)(SAN)。
默認情況下,Kubernetes 網(wǎng)絡(luò)策略允許 吊艙 從任何地方接收流量。如果你不擔心吊艙的安全性,那么這可能沒問題。但是,如果你正在運行關(guān)鍵工作負載,則需要保護吊艙??刂萍簝?nèi)的流量(包括入口和出口流量),可以通過網(wǎng)絡(luò)策略來實現(xiàn)。
要啟用網(wǎng)絡(luò)策略,你需要一個支持網(wǎng)絡(luò)策略的網(wǎng)絡(luò)插件。否則,你應(yīng)用的任何規(guī)則都將變得毫無用處。
Kubernetes.io 上列出了不同的網(wǎng)絡(luò)插件:
- CNI 插件:遵循 容器網(wǎng)絡(luò)接口(CNI)規(guī)范,旨在實現(xiàn)互操作性。
- Kubernetes 遵循 CNI 規(guī)范的 v0.4.0 版本。
- Kubernetes 插件:使用橋接器和主機本地 CNI 插件實現(xiàn)基本的
cbr0
。
應(yīng)用網(wǎng)絡(luò)策略
要應(yīng)用網(wǎng)絡(luò)策略,你需要一個工作中的 Kubernetes 集群,并有支持網(wǎng)絡(luò)策略的網(wǎng)絡(luò)插件。
但首先,你需要了解如何在 Kubernetes 的環(huán)境使用網(wǎng)絡(luò)策略。Kubernetes 網(wǎng)絡(luò)策略允許 吊艙 從任何地方接收流量。這并不是理想情況。為了吊艙安全,你必須了解吊艙是可以在 Kubernetes 架構(gòu)內(nèi)進行通信的端點。
1、使用 podSelector
進行吊艙間的通信:
- namespaceSelector:
matchLabels:
project: myproject
2、使用 namespaceSelector
和/或 podSelector
和 namespaceSelector
的組合進行命名空間之間的通信和命名空間到吊艙的通信。:
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
3、對于吊艙的 IP 塊通信,使用 ipBlock
定義哪些 IP CIDR 塊決定源和目的。
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
注意吊艙、命名空間和基于 IP 的策略之間的區(qū)別。對于基于吊艙和命名空間的網(wǎng)絡(luò)策略,使用選擇器來控制流量,而對基于 IP 的網(wǎng)絡(luò)策略,使用 IP 塊(CIDR 范圍)來定義控制。
把它們放在一起,一個網(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ò)策略,請注意 spec
部分。在此部分下,帶有標簽 app=backend
的 podSelector
是我們的網(wǎng)絡(luò)策略的目標。簡而言之,網(wǎng)絡(luò)策略保護給定命名空間內(nèi)稱為 backend
的應(yīng)用程序。
此部分也有 policyTypes
定義。此字段指示給定策略是否適用于選定吊艙的入口流量、選定吊艙的出口流量,或兩者皆有。
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
- Egress
現(xiàn)在,請看 Ingress
(入口)和 Egress
(出口)部分。該定義規(guī)定了網(wǎng)絡(luò)策略的控制。
首先,檢查 ingress from
部分。
此實例中,網(wǎng)絡(luò)策略允許從以下位置進行吊艙連接:
ipBlock
- 允許 172.17.0.0/16
- 拒絕 192.168.1.0/24
namespaceSelector
myproject
: 允許來自此命名空間并具有相同標簽 project=myproject 的所有吊艙。
podSelector
frontend
: 允許與標簽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 進行連接
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
網(wǎng)絡(luò)策略的限制
僅靠網(wǎng)絡(luò)策略無法完全保護你的 Kubernetes 集群。你可以使用操作系統(tǒng)組件或 7 層網(wǎng)絡(luò)技術(shù)來克服已知限制。你需要記住,網(wǎng)絡(luò)策略只能解決 IP 地址和端口級別的安全問題 —— 即開放系統(tǒng)互聯(lián)(OSI)中的第 3 層或第 4 層。
為了解決網(wǎng)絡(luò)策略無法處理的安全要求,你需要使用其它安全解決方案。以下是你需要知道的一些 用例,在這些用例中,網(wǎng)絡(luò)策略需要其他技術(shù)的增強。
總結(jié)
了解 Kubernetes 的網(wǎng)絡(luò)策略很重要,因為它是實現(xiàn)(但不是替代)你通常在數(shù)據(jù)中心設(shè)置中使用的防火墻角色的一種方式,但適用于 Kubernetes。將此視為容器安全的第一層,僅僅依靠網(wǎng)絡(luò)策略并不是一個完整的安全解決方案。
網(wǎng)絡(luò)策略使用選擇器和標簽在吊艙和命名空間上實現(xiàn)安全性。此外,網(wǎng)絡(luò)策略還可以通過 IP 范圍實施安全性。
充分理解網(wǎng)絡(luò)策略是在 Kubernetes 環(huán)境中安全采用容器化的一項重要技能。