1. 項(xiàng)目概述為什么微服務(wù)需要“門禁系統(tǒng)”在Kubernetes集群里跑微服務(wù)就像在一個(gè)大型開放式辦公區(qū)里安排了幾十個(gè)不同的項(xiàng)目組。起初大家為了協(xié)作方便所有工位都是打通的任何一個(gè)人都可以隨時(shí)走到另一個(gè)人的工位旁交流甚至翻看對(duì)方的資料。這在項(xiàng)目初期、團(tuán)隊(duì)規(guī)模小的時(shí)候效率確實(shí)很高。但隨著項(xiàng)目組微服務(wù)越來(lái)越多業(yè)務(wù)越來(lái)越復(fù)雜這種完全開放的模式就會(huì)帶來(lái)大麻煩。想象一下一個(gè)負(fù)責(zé)內(nèi)部數(shù)據(jù)處理的“財(cái)務(wù)組”其敏感數(shù)據(jù)能被任何一個(gè)“前端展示組”或“外部接口組”的服務(wù)隨意訪問又或者一個(gè)存在漏洞的“用戶頭像上傳服務(wù)”被攻破后攻擊者可以以此為跳板在辦公區(qū)內(nèi)“暢通無(wú)阻”直接攻擊最核心的“支付服務(wù)”或“數(shù)據(jù)庫(kù)服務(wù)”。這種混亂和風(fēng)險(xiǎn)就是我們?cè)贙ubernetes中常說(shuō)的“東西向流量”安全問題。Kubernetes Network Policy網(wǎng)絡(luò)策略就是為了解決這個(gè)問題而生的“門禁系統(tǒng)”和“內(nèi)部管理?xiàng)l例”。它不是一個(gè)獨(dú)立的網(wǎng)絡(luò)插件而是一個(gè)Kubernetes原生的API對(duì)象用于聲明式地定義Pod組之間以及Pod與外部世界之間的網(wǎng)絡(luò)通信規(guī)則。其核心思想就是“默認(rèn)拒絕顯式允許”也就是我們常說(shuō)的白名單策略。在沒有定義任何Network Policy的命名空間里所有Pod默認(rèn)是可以互相通信的這相當(dāng)于辦公區(qū)沒有門禁。而一旦你創(chuàng)建了Network Policy它就相當(dāng)于給特定的“辦公室”Pod組安裝了門禁卡系統(tǒng)只有持有“門卡”符合策略規(guī)則的流量才能進(jìn)出。這個(gè)項(xiàng)目要探討的正是如何為你的微服務(wù)架構(gòu)設(shè)計(jì)和實(shí)施這套精細(xì)的“白名單門禁系統(tǒng)”。它不僅僅是開啟一個(gè)功能更涉及對(duì)微服務(wù)依賴關(guān)系的深刻理解、對(duì)安全模型的權(quán)衡以及在實(shí)際運(yùn)維中的落地實(shí)踐。對(duì)于從開發(fā)轉(zhuǎn)型運(yùn)維、或是正在構(gòu)建云原生安全體系的工程師來(lái)說(shuō)掌握Network Policy是確保Kubernetes集群從“能用”走向“好用且安全”的關(guān)鍵一步。2. Network Policy 核心概念與工作原理拆解要玩轉(zhuǎn)Network Policy首先得理解它的幾個(gè)核心“零件”以及它們是如何協(xié)同工作的。很多人看了官方文檔依然云里霧里問題往往出在沒有把這些抽象概念和實(shí)際網(wǎng)絡(luò)模型對(duì)應(yīng)起來(lái)。2.1 策略模型選擇器、規(guī)則與流量方向Network Policy的本質(zhì)是“誰(shuí)Pod在什么條件下可以和誰(shuí)通信”。它通過三個(gè)核心部分來(lái)定義Pod選擇器 (podSelector)用于確定此策略要施加于哪些Pod。你可以通過標(biāo)簽Labels來(lái)精確定位。例如podSelector: matchLabels: app: order-service表示這個(gè)策略作用于所有帶有apporder-service標(biāo)簽的Pod。如果podSelector為空{(diào)}則策略會(huì)應(yīng)用于當(dāng)前命名空間下的所有Pod。策略類型 (policyTypes)定義策略規(guī)則是針對(duì)哪種流量方向。可選Ingress入站別人訪問我、Egress出站我訪問別人或兩者都包含。這是很多人容易忽略但至關(guān)重要的字段它決定了你的規(guī)則是管“進(jìn)門”還是管“出門”。規(guī)則 (ingress/egress)具體的白名單條目。ingress(入站規(guī)則)一個(gè)列表每個(gè)條目定義了一組被允許的入站流量來(lái)源。每個(gè)條目可以包含from和ports兩部分。egress(出站規(guī)則)一個(gè)列表每個(gè)條目定義了一組被允許的出站流量目的地。每個(gè)條目可以包含to和ports兩部分。在from和to字段中你可以通過四種選擇器來(lái)指定對(duì)端podSelector: 選擇同一命名空間內(nèi)的其他Pod。namespaceSelector: 選擇特定的命名空間其內(nèi)的所有Pod或符合特定標(biāo)簽的Pod。ipBlock: 以CIDR格式指定IP地址段。組合使用namespaceSelector和podSelector可以在一個(gè)from/to塊中同時(shí)使用此時(shí)表示“在指定命名空間中且符合指定標(biāo)簽的Pod”兩者是“與”的關(guān)系。2.2 底層實(shí)現(xiàn)依賴CNI插件與策略控制器這是一個(gè)關(guān)鍵的實(shí)操心得Network Policy API本身只是個(gè)“說(shuō)明書”它自己不會(huì)執(zhí)行任何網(wǎng)絡(luò)攔截。實(shí)際的“保安”數(shù)據(jù)平面 enforcement是由支持Network Policy的CNI容器網(wǎng)絡(luò)接口插件來(lái)完成的。支持策略的CNI插件常見的如Calico, Cilium, Weave Net, Antrea等。Flannel的默認(rèn)配置VXLAN后端是不支持Network Policy的這是初學(xué)者最大的一個(gè)坑。如果你在用Flannel又想玩策略要么換插件要么使用Flannel的host-gw后端并結(jié)合Calico的typha組件但這比較復(fù)雜。策略控制器CNI插件中負(fù)責(zé)監(jiān)聽Kubernetes API發(fā)現(xiàn)Network Policy變化并將其轉(zhuǎn)換為底層網(wǎng)絡(luò)設(shè)備如iptables, eBPF或插件的自有數(shù)據(jù)平面具體規(guī)則的組件。所以你的第一步永遠(yuǎn)是確認(rèn)你的Kubernetes集群網(wǎng)絡(luò)插件是否支持并已啟用Network Policy功能?？梢酝ㄟ^kubectl get daemonset -n kube-system查看網(wǎng)絡(luò)插件相關(guān)的DaemonSet或者查閱集群部署文檔。2.3 策略的疊加與評(píng)估邏輯多個(gè)Network Policy如何同時(shí)作用于一個(gè)Pod規(guī)則是“疊加”且“寬松”的。疊加一個(gè)Pod可以匹配多個(gè)Network Policy。例如一個(gè)Pod可以同時(shí)被一個(gè)“允許來(lái)自前端訪問”的策略和一個(gè)“允許訪問數(shù)據(jù)庫(kù)”的策略選中。寬松的OR邏輯對(duì)于入站流量只要任意一個(gè)選中該P(yáng)od的Network Policy的ingress規(guī)則允許該流量則流量被允許。出站流量同理。這意味著你不能通過創(chuàng)建多個(gè)策略來(lái)“收緊”規(guī)則比如一個(gè)策略允許來(lái)自A另一個(gè)策略沒提A結(jié)果A還是能進(jìn)來(lái)。要拒絕特定流量必須依賴精確的白名單讓不希望的流量不在任何白名單內(nèi)。隔離模式如果Pod被任何一條policyTypes包含Ingress的Network Policy選中則其默認(rèn)的“允許所有入站”狀態(tài)被打破進(jìn)入“默認(rèn)拒絕所有入站”狀態(tài)只有白名單允許的流量可入。Egress同理。理解了這個(gè)邏輯你就明白設(shè)計(jì)策略時(shí)思考的應(yīng)該是“我需要允許哪些必要的連接”而不是“我要禁止哪些連接”。3. 微服務(wù)白名單策略設(shè)計(jì)實(shí)戰(zhàn)理論說(shuō)再多不如動(dòng)手畫一張自己系統(tǒng)的“通信地圖”。我們以一個(gè)典型的電商微服務(wù)簡(jiǎn)化架構(gòu)為例設(shè)計(jì)一套漸進(jìn)式的網(wǎng)絡(luò)策略。假設(shè)我們有如下服務(wù)frontend: 前端API網(wǎng)關(guān)標(biāo)簽app: frontend, tier: gatewayuser-service: 用戶服務(wù)標(biāo)簽app: user-service, tier: backendorder-service: 訂單服務(wù)標(biāo)簽app: order-service, tier: backendproduct-service: 商品服務(wù)標(biāo)簽app: product-service, tier: backendredis: 緩存標(biāo)簽app: redis, tier: cachepostgres: 主數(shù)據(jù)庫(kù)標(biāo)簽app: postgres, tier: data一個(gè)外部的支付網(wǎng)關(guān)APIapi.payment.com所有服務(wù)部署在default命名空間。3.1 第一步基礎(chǔ)隔離——按層級(jí)劃分安全域最粗粒度的策略是先按“層級(jí)”隔離。例如后端服務(wù)不應(yīng)該被前端直接訪問除了通過API網(wǎng)關(guān)數(shù)據(jù)庫(kù)層只接受來(lái)自后端服務(wù)的訪問。策略1數(shù)據(jù)庫(kù)層只接受后端服務(wù)訪問apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend-to-data namespace: default spec: podSelector: matchLabels: tier: data # 選擇數(shù)據(jù)庫(kù)Pod policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: tier: backend # 允許來(lái)自后端服務(wù)的流量 ports: - protocol: TCP port: 5432 # PostgreSQL端口這個(gè)策略為所有tierdata的Pod目前是Postgres設(shè)置了一個(gè)入站白名單僅允許來(lái)自tierbackend的Pod訪問其5432端口。策略2后端服務(wù)內(nèi)部互通我們?cè)试S所有tierbackend的服務(wù)之間互相通信因?yàn)樗鼈兛赡苡袃?nèi)部API調(diào)用。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend-internal namespace: default spec: podSelector: matchLabels: tier: backend policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: tier: backend這個(gè)策略很簡(jiǎn)單允許所有后端服務(wù)互相訪問所有端口。這雖然比完全開放好但粒度仍然很粗。3.2 第二步精細(xì)控制——按應(yīng)用定義通信矩陣現(xiàn)在我們來(lái)實(shí)施更精細(xì)的、基于具體應(yīng)用的白名單。我們需要梳理每個(gè)服務(wù)的真實(shí)依賴。user-service需要訪問postgres:5432 需要訪問redis:6379。order-service需要訪問postgres:5432 需要訪問redis:6379 需要調(diào)用user-service驗(yàn)證用戶 需要調(diào)用product-service驗(yàn)證商品。product-service需要訪問postgres:5432 需要訪問redis:6379。frontend需要被集群外部的用戶訪問通常由Ingress Controller處理策略可能作用于Ingress Controller而非frontend本身 需要調(diào)用user-service,order-service,product-service的API端口比如8080。注意frontend作為網(wǎng)關(guān)它訪問后端服務(wù)的流量是出站Egress方向。而后端服務(wù)接受frontend的調(diào)用是入站Ingress方向。我們需要雙向配置。策略3為order-service定義精確入站規(guī)則apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: order-service-ingress namespace: default spec: podSelector: matchLabels: app: order-service policyTypes: - Ingress ingress: # 允許來(lái)自前端網(wǎng)關(guān)的API調(diào)用 - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080 # order-service的服務(wù)端口 # 允許來(lái)自其他后端服務(wù)的內(nèi)部調(diào)用如果需要的話這里假設(shè)不需要由order-service主動(dòng)調(diào)用別人 # 注意這里沒有允許來(lái)自u(píng)ser-service/product-service的入站因?yàn)閛rder-service是調(diào)用方。這個(gè)策略只允許frontend訪問order-service的8080端口。即使同是tier:backend的user-service也無(wú)法直接訪問它除非有明確規(guī)則。策略4為order-service定義精確出站規(guī)則apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: order-service-egress namespace: default spec: podSelector: matchLabels: app: order-service policyTypes: - Egress egress: # 允許訪問user-service的API端口 - to: - podSelector: matchLabels: app: user-service ports: - protocol: TCP port: 8080 # 允許訪問product-service的API端口 - to: - podSelector: matchLabels: app: product-service ports: - protocol: TCP port: 8080 # 允許訪問postgres數(shù)據(jù)庫(kù) - to: - podSelector: matchLabels: app: postgres ports: - protocol: TCP port: 5432 # 允許訪問redis緩存 - to: - podSelector: matchLabels: app: redis ports: - protocol: TCP port: 6379 # 允許訪問外部支付網(wǎng)關(guān)DNS解析和HTTPS - to: - ipBlock: cidr: 0.0.0.0/0 # 通常我們需要更精確的IP這里示例用0.0.0.0/0 ports: - protocol: TCP port: 443 # 關(guān)鍵允許訪問kube-dns進(jìn)行服務(wù)發(fā)現(xiàn) - to: - namespaceSelector: {} podSelector: matchLabels: k8s-app: kube-dns ports: - protocol: UDP port: 53 - protocol: TCP port: 53這個(gè)策略是精髓。它明確了order-service只能訪問user-service和product-service的8080端口。訪問postgres的5432端口和redis的6379端口。訪問外部支付網(wǎng)關(guān)的443端口。必須能訪問集群DNSkube-dns或coreDNS否則無(wú)法將服務(wù)名如user-service解析為Pod IP。這是一個(gè)極易忽略的踩坑點(diǎn)。注意namespaceSelector: {}匹配所有命名空間因?yàn)镈NS服務(wù)通常在kube-system命名空間。3.3 第三步命名空間隔離與跨命名空間訪問更佳實(shí)踐是將不同層級(jí)或不同業(yè)務(wù)線的服務(wù)放到不同的命名空間例如gateway,backend,data。這時(shí)就需要使用namespaceSelector。假設(shè)frontend在gateway命名空間后端服務(wù)在backend命名空間。策略5允許跨命名空間訪問apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-gateway-to-backend namespace: backend # 策略放在后端命名空間 spec: podSelector: matchLabels: tier: backend # 保護(hù)后端所有Pod policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: name: gateway # 選擇名為gateway的命名空間 podSelector: matchLabels: app: frontend # 且Pod是frontend ports: - protocol: TCP port: 8080同時(shí)你需要給gateway命名空間打上標(biāo)簽name: gateway(kubectl label namespace gateway namegateway)。4. 實(shí)操部署、驗(yàn)證與調(diào)試全流程設(shè)計(jì)好策略YAML文件只是開始如何安全地部署和驗(yàn)證才是重中之重。莽撞地應(yīng)用一個(gè)嚴(yán)格的策略可能導(dǎo)致服務(wù)瞬間中斷。4.1 漸進(jìn)式部署與“逃生艙”策略絕對(duì)不要一次性在生產(chǎn)環(huán)境應(yīng)用所有嚴(yán)格的策略。采用漸進(jìn)式部署首先應(yīng)用“僅審計(jì)Audit”或“默認(rèn)允許Allow All”策略一些CNI插件如Calico支持策略模式設(shè)置可以先設(shè)為日志記錄模式觀察流量是否符合預(yù)期而不實(shí)際攔截。如果插件不支持可以先應(yīng)用一個(gè)允許所有流量的策略作為基線確保它優(yōu)先級(jí)最低。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-as-baseline namespace: default spec: podSelector: {} # 選擇所有Pod policyTypes: - Ingress - Egress ingress: - {} egress: - {}這個(gè)策略允許所有進(jìn)出流量。后續(xù)更具體的策略會(huì)與之疊加由于寬松的OR邏輯只要具體策略允許流量就通行這個(gè)兜底策略實(shí)際上只在“沒有其他策略匹配”時(shí)生效。但把它放在這里可以在你部署新策略出錯(cuò)時(shí)防止完全的網(wǎng)絡(luò)中斷。從最核心、依賴最少的服務(wù)開始比如先給redis、postgres這類數(shù)據(jù)層服務(wù)應(yīng)用策略。因?yàn)樗鼈兊目蛻舳撕蠖朔?wù)相對(duì)固定容易梳理。應(yīng)用一個(gè)驗(yàn)證一個(gè)應(yīng)用策略后立即進(jìn)行驗(yàn)證。從集群內(nèi)測(cè)試使用kubectl run一個(gè)臨時(shí)調(diào)試Pod如busybox嘗試從它內(nèi)部curl或nc目標(biāo)服務(wù)。從業(yè)務(wù)層面測(cè)試運(yùn)行服務(wù)的自動(dòng)化測(cè)試套件或進(jìn)行核心業(yè)務(wù)流程的手動(dòng)測(cè)試。觀察服務(wù)日志和監(jiān)控查看是否有連接超時(shí)、拒絕連接的報(bào)錯(cuò)。準(zhǔn)備好快速回滾在應(yīng)用策略前保存當(dāng)前的策略YAML或者使用kubectl apply -f (kubectl get networkpolicy -o yaml)備份整個(gè)命名空間的策略。一旦出現(xiàn)問題立即kubectl delete networkpolicy problematic-policy或重新應(yīng)用舊配置。4.2 驗(yàn)證工具與命令查看策略kubectl get networkpolicy --all-namespaces kubectl describe networkpolicy policy-name -n namespace使用臨時(shí)Pod進(jìn)行網(wǎng)絡(luò)測(cè)試# 啟動(dòng)一個(gè)包含curl和nc的調(diào)試Pod kubectl run test-pod --imagenicolaka/netshoot -it --rm --restartNever -- /bin/bash # 進(jìn)入Pod后測(cè)試連接 curl -v http://order-service.default.svc.cluster.local:8080/health nc -zv postgres 5432 # 測(cè)試外部網(wǎng)絡(luò)如果策略限制出站 curl -v https://api.payment.com nslookup kubernetes.default.svc.cluster.local利用CNI插件提供的工具Calico: 可以使用calicoctl查看端點(diǎn)的安全策略和狀態(tài)。Cilium: 提供了強(qiáng)大的cilium命令行工具和Hubble可視化界面可以清晰地看到流量的允許/拒絕情況是調(diào)試的神器。4.3 常見問題排查實(shí)錄問題1服務(wù)突然無(wú)法訪問日志顯示“Connection refused”或超時(shí)。排查思路檢查Pod選擇器確認(rèn)你的Network Policy的podSelector是否準(zhǔn)確匹配了目標(biāo)Pod的標(biāo)簽。用kubectl get pod --show-labels核對(duì)。檢查策略類型你是否只配置了Ingress但流量是出站Egress或者反之。確認(rèn)policyTypes字段。檢查端口定義規(guī)則中ports定義的協(xié)議TCP/UDP和端口號(hào)是否與目標(biāo)服務(wù)監(jiān)聽的端口一致。注意容器端口和Service端口的區(qū)別Network Policy作用于Pod IP層面通常是容器端口。檢查DNS如果錯(cuò)誤信息是域名無(wú)法解析或者服務(wù)發(fā)現(xiàn)失敗請(qǐng)確保你的出站Egress策略允許訪問kube-dns服務(wù)端口53 UDP/TCP并且指向正確的命名空間通常是kube-system。檢查策略疊加記住多個(gè)策略是“OR”邏輯。如果Pod被任何一條策略選中默認(rèn)拒絕就會(huì)生效。確認(rèn)是否存在一條“默認(rèn)拒絕所有”的策略意外選中了你的Pod而又沒有其他策略允許你的流量。問題2允許了特定Pod但流量仍然不通。排查思路檢查命名空間如果通信雙方在不同命名空間你必須使用namespaceSelector單純的podSelector只匹配同一命名空間內(nèi)的Pod。檢查標(biāo)簽更新Pod的標(biāo)簽是否在創(chuàng)建后被修改Network Policy在Pod創(chuàng)建時(shí)或策略更新時(shí)生效。如果Pod的標(biāo)簽變了可能需要重啟Pod或等待策略重新計(jì)算取決于CNI插件。檢查CNI插件狀態(tài)查看網(wǎng)絡(luò)插件Pod的日志是否有錯(cuò)誤。kubectl logs -n kube-system cni-pod-name。問題3如何知道當(dāng)前Pod實(shí)際生效的策略是什么方案這依賴于CNI插件。對(duì)于Calico可以calicoctl get wep和工作負(fù)載端點(diǎn)。對(duì)于Cilium可以用cilium endpoint get pod-id或通過Hubble UI查看。通用方法是結(jié)合kubectl describe networkpolicy和 Pod的標(biāo)簽進(jìn)行人工推導(dǎo)。5. 高級(jí)模式與生產(chǎn)環(huán)境考量當(dāng)基本策略穩(wěn)定后可以考慮更高級(jí)的模式來(lái)提升安全性和可管理性。5.1 默認(rèn)拒絕所有流量這是安全最佳實(shí)踐在每個(gè)命名空間創(chuàng)建一個(gè)“默認(rèn)拒絕所有”的策略然后在此基礎(chǔ)上逐個(gè)添加白名單。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: my-app spec: podSelector: {} # 選擇所有Pod policyTypes: - Ingress - Egress # 不指定任何 ingress/egress 規(guī)則即拒絕所有進(jìn)出流量。重要提示應(yīng)用此策略前必須確保已經(jīng)為必要的系統(tǒng)組件如DNS、監(jiān)控Agent、日志收集Sidecar和你的應(yīng)用Pod創(chuàng)建了允許規(guī)則否則集群內(nèi)部通信會(huì)立刻中斷。5.2 為系統(tǒng)組件創(chuàng)建豁免策略集群系統(tǒng)組件CoreDNS、監(jiān)控棧、Ingress Controller、Service Mesh Sidecar等需要特殊關(guān)照。通常的做法是為它們所在的命名空間如kube-system,monitoring或特定標(biāo)簽的Pod創(chuàng)建寬松的策略或者確保你的應(yīng)用命名空間的“默認(rèn)拒絕”策略不會(huì)影響到與這些系統(tǒng)組件的通信。例如允許所有Pod訪問kube-system命名空間下DNS服務(wù)的規(guī)則是必須的。5.3 與服務(wù)網(wǎng)格Service Mesh的協(xié)同如果你使用了Istio、Linkerd等服務(wù)網(wǎng)格情況會(huì)變得復(fù)雜。服務(wù)網(wǎng)格通常會(huì)在Pod中注入Sidecar代理如Envoy所有流量都被Sidecar劫持和管理。這時(shí)Kubernetes Network Policy是在哪個(gè)層面生效呢通常的協(xié)同模式Network Policy作用于三層/四層IP和端口而服務(wù)網(wǎng)格的策略作用于七層HTTP/gRPC等應(yīng)用層協(xié)議。你可以用Network Policy做粗粒度的“區(qū)域隔離”例如只允許帶有特定版本標(biāo)簽的Sidecar之間通信而用服務(wù)網(wǎng)格做細(xì)粒度的“應(yīng)用層策略”如基于JWT的認(rèn)證、基于路徑的訪問控制。一個(gè)常見的實(shí)踐使用Network Policy確保流量只能從注入了Sidecar的Pod發(fā)出或接收強(qiáng)制所有流量經(jīng)過網(wǎng)格。例如只允許帶有sidecar.istio.io/inject: “true”標(biāo)簽的Pod之間互相通信。注意事項(xiàng)兩者配置重疊可能導(dǎo)致沖突需要仔細(xì)設(shè)計(jì)和測(cè)試。建議明確分工避免在兩層上對(duì)同一流量做重復(fù)且可能矛盾的規(guī)則。5.4 策略即代碼與GitOps對(duì)于生產(chǎn)環(huán)境手動(dòng)管理YAML文件是不可靠的。應(yīng)將Network Policy視為基礎(chǔ)設(shè)施即代碼IaC的一部分。版本控制所有策略YAML文件存入Git倉(cāng)庫(kù)。代碼評(píng)審策略的變更應(yīng)像應(yīng)用代碼一樣經(jīng)過評(píng)審因?yàn)橐粋€(gè)錯(cuò)誤策略可能導(dǎo)致生產(chǎn)事故。CI/CD流水線通過CI流水線進(jìn)行簡(jiǎn)單的語(yǔ)法驗(yàn)證如kubectl apply --dry-runclient -f和策略模擬測(cè)試。GitOps工具使用ArgoCD、Flux等工具將策略的期望狀態(tài)聲明在Git中自動(dòng)同步到集群。這確保了集群狀態(tài)與代碼倉(cāng)庫(kù)的一致性并方便回滾。實(shí)施Kubernetes Network Policy是一個(gè)從粗到細(xì)、持續(xù)迭代的過程。它沒有銀彈最好的策略源于你對(duì)自身系統(tǒng)架構(gòu)和數(shù)據(jù)流的深刻理解。開始時(shí)可能會(huì)覺得繁瑣甚至?xí)驗(yàn)椴呗藻e(cuò)誤導(dǎo)致一些故障但一旦這套白名單體系建立起來(lái)它將成為你的微服務(wù)架構(gòu)中最堅(jiān)實(shí)的一道安全防線讓你在應(yīng)對(duì)安全審計(jì)和潛在的網(wǎng)絡(luò)攻擊時(shí)擁有十足的底氣。