在防火墻后部署 Kubernetes 的技術(shù)
防火墻環(huán)境下部署和管理 Kubernetes 的可行策略
譯自Deploy Kubernetes Behind Firewalls Using These Techniques，作者 Mohan Sitaram。
隨著 Kubernetes 和云原生系統(tǒng)成為部署和管理現(xiàn)代應(yīng)用程序的事實(shí)標(biāo)準(zhǔn)，它們擴(kuò)展到受限或防火墻環(huán)境帶來了獨(dú)特的挑戰(zhàn)。這些環(huán)境通常受監(jiān)管合規(guī)性、安全問題或組織政策驅(qū)動(dòng)，這些因素帶來了架構(gòu)、運(yùn)營和安全方面的障礙。本文深入探討了在防火墻后部署 Kubernetes 集群的復(fù)雜性，提供了克服這些障礙的解決方案和策略。
防火墻或受限環(huán)境限制了外部互聯(lián)網(wǎng)訪問以確保數(shù)據(jù)安全并保護(hù)系統(tǒng)免受未經(jīng)授權(quán)的入侵。這些環(huán)境在金融、醫(yī)療保健和政府等具有嚴(yán)格監(jiān)管要求的行業(yè)中很常見。在這些環(huán)境中，通常只允許特定類型的流量，并且需要嚴(yán)格的監(jiān)督。雖然這些控制措施增強(qiáng)了安全性，但它們?yōu)?Kubernetes 等現(xiàn)代云原生基礎(chǔ)設(shè)施帶來了重大挑戰(zhàn)，而 Kubernetes 依賴于互聯(lián)網(wǎng)訪問才能實(shí)現(xiàn)集群管理、鏡像拉取和外部 API 通信等功能。
在防火墻環(huán)境中部署 Kubernetes 的挑戰(zhàn)
- 鏡像管理和分發(fā)：Kubernetes 應(yīng)用程序需要從容器注冊表（如 Docker Hub、gcr.io 或 quay.io）提供容器鏡像。在防火墻環(huán)境中，訪問這些注冊表通常受到限制或完全被阻止。這可能會阻止鏡像拉取，從而阻礙應(yīng)用程序的部署和升級。
解決方案：為了解決這個(gè)問題，企業(yè)可以使用具有存儲庫復(fù)制或拉取緩存功能的注冊表，在防火墻內(nèi)本地托管容器鏡像。這些注冊表可以以受控方式復(fù)制或從外部注冊表拉取鏡像，確保必要的容器鏡像可用，而無需持續(xù)訪問互聯(lián)網(wǎng)。Harbor 等注冊表為這些環(huán)境提供了安全的內(nèi)部鏡像存儲庫。此外，利用鏡像提升工作流可以確保只有經(jīng)過驗(yàn)證的外部來源鏡像才能進(jìn)入安全注冊表。
我使用過的另一種方法是通過網(wǎng)關(guān)或代理服務(wù)器復(fù)制鏡像，該服務(wù)器與源注冊表和目標(biāo)注冊表都具有連接性。當(dāng)源注冊表和目標(biāo)注冊表的 capabilities 未知時(shí)，此解決方案可能有效。imgpkg、crane 或 skopeo 等工具可以在跨越防火墻邊界的注冊表之間復(fù)制鏡像。例如，imgpkg 打包格式將應(yīng)用程序的 helm 圖表及其容器鏡像捆綁為一個(gè)單元。imgpkg 捆綁包可以從源注冊表導(dǎo)出為 tar 存檔到代理服務(wù)器的本地文件系統(tǒng)。然后，此 tar 存檔可以推送到防火墻后的注冊表，imgpkg 確保捆綁包中應(yīng)用程序的 helm 圖表中的注冊表引用會自動(dòng)更新為指向目標(biāo)注冊表。
- 集群管理和控制平面訪問：Kubernetes 的控制平面（API 服務(wù)器等）必須與工作節(jié)點(diǎn)和外部云 API 通信才能管理集群。但是，在防火墻環(huán)境中，外部訪問這些 API 或控制平面組件通常被阻止或限制，這對監(jiān)控、擴(kuò)展和控制集群提出了重大挑戰(zhàn)。
解決方案：組織可以建立反向代理和 VPN 隧道技術(shù)來克服這個(gè)問題。部署在非軍事化區(qū)域 (DMZ) 中的反向代理可以處理來自防火墻內(nèi)的 API 請求，同時(shí)提供安全的入口點(diǎn)。此外，堡壘主機(jī)和 VPN 網(wǎng)關(guān)可以允許對 Kubernetes 控制平面進(jìn)行受控的、安全的訪問。這些主機(jī)位于內(nèi)部網(wǎng)絡(luò)之外，但充當(dāng)受限環(huán)境和外部服務(wù)之間的橋梁，允許管理員與集群交互，而不會違反防火墻策略。
例如，Azure 允許創(chuàng)建部署在企業(yè)私有網(wǎng)絡(luò)中的“私有” AKS 集群。出于安全原因，默認(rèn)情況下，對私有 AKS 集群的控制平面的訪問受到限制。但 Azure 還提供 Azure Bastion 等解決方案，該解決方案提供從外部世界安全訪問私有集群。用戶通過本地計(jì)算機(jī)上的 RDP 或 SSH 連接到 Azure Bastion，并可以通過代理訪問私有集群。Bastion 負(fù)責(zé)保護(hù)到私有集群的流量。
- 外部依賴和 DNS 解析：有時(shí)，在隔離的 Kubernetes 集群中運(yùn)行的應(yīng)用程序可能需要拉取外部依賴項(xiàng)，為此它可能需要解析防火墻外部的主機(jī)名。從 Pod 內(nèi)部可能無法直接訪問公共 DNS（如 Google DNS 或 Cloudflare DNS），并且應(yīng)用程序可能無法拉取依賴項(xiàng)并無法啟動(dòng)。這將迫使組織或應(yīng)用程序開發(fā)人員在防火墻內(nèi)解決依賴項(xiàng)，而這可能并非總是可行。
解決方案：在 CoreDNS 中使用 DNS 轉(zhuǎn)發(fā)。CoreDNS 是 Kubernetes 集群中的默認(rèn) DNS 解析器，可以配置為從防火墻內(nèi)部解析外部 DNS 查詢?？梢孕薷?CoreDNS 以將 DNS 查詢轉(zhuǎn)發(fā)到特定主機(jī)名（如www.example.com）到外部解析器，并將所有其他查詢解析到防火墻內(nèi)。這可以通過使用“forward”CoreDNS插件來完成，將www.example.com的查詢轉(zhuǎn)發(fā)到 Google 或 CloudFlare DNS，并將所有其他內(nèi)容（用“.”表示）轉(zhuǎn)發(fā)到本地解析器，只需將它們指向 /etc/resolv.conf 即可。這確保了關(guān)鍵的 DNS 解析不會被防火墻策略阻止，并且還允許防火墻管理員通過僅允許特定外部查詢來保持網(wǎng)絡(luò)安全。
- 更新、補(bǔ)丁和 Kubernetes 組件：定期更新和修補(bǔ) Kubernetes 組件對于維護(hù)安全、合規(guī)性和性能至關(guān)重要。但是，在防火墻環(huán)境中，自動(dòng)更新可能會被阻止，使集群容易受到安全風(fēng)險(xiǎn)的攻擊。
解決方案：使用本地鏡像和內(nèi)部容器注冊表來更新集群。Kubernetes 安裝工具（如 Kubespray）允許在離線環(huán)境中進(jìn)行集群管理。通過 Kubespray 安裝和修補(bǔ) Kubernetes 需要訪問靜態(tài)文件（如 kubectl 和 kubeadm）、操作系統(tǒng)包以及核心 Kubernetes 組件的一些容器鏡像。靜態(tài)文件可以通過在防火墻內(nèi)運(yùn)行 nginx/HAproxy 服務(wù)器來提供。操作系統(tǒng)包可以通過部署 yum 或 Debian 存儲庫的本地鏡像來獲取。Kubespray 所需的容器鏡像可以通過運(yùn)行本地實(shí)例的“kind”或 docker 注冊表來提供，這些注冊表中預(yù)先填充了鏡像。此外，公司可以使用持續(xù)集成/持續(xù)交付 (CI/CD) 管道以受控方式處理更新，在將更改推廣到生產(chǎn)集群之前，在暫存集群上進(jìn)行本地測試和驗(yàn)證。GitOps 是 CI/CD 的一個(gè)子類別，它會自動(dòng)將更改部署到目標(biāo)環(huán)境，這些更改由對 Git 存儲庫的提交觸發(fā)。暫存和生產(chǎn)集群可以映射到不同的 Git 分支，并且可以通過首先將更改提交到暫存分支，對其進(jìn)行徹底測試，然后才將相同的更改提交到生產(chǎn)分支來策略性地推出升級和補(bǔ)丁。這確保了集群即使沒有自動(dòng)更新也能使用最新的安全補(bǔ)丁。
- 第三方集成和監(jiān)控：現(xiàn)代 Kubernetes 應(yīng)用程序通常依賴于第三方集成（如 Datadog）和外部存儲解決方案（如 AWS S3 或 Google Cloud）存儲。在防火墻環(huán)境中，出站流量受到限制，阻止了與這些云托管服務(wù)的直接通信。
解決方案：組織可以在其防火墻環(huán)境中部署自托管的替代方案來維護(hù)可觀察性和監(jiān)控。例如，可以在內(nèi)部部署 Prometheus 和 Grafana 來處理指標(biāo)和可視化，而分布式存儲解決方案（如 Ceph 或 MinIO）可以替換外部云存儲。這些工具可以復(fù)制外部服務(wù)的功，同時(shí)確保所有數(shù)據(jù)安全地保留在防火墻內(nèi)。自托管替代方案的容器鏡像和 helm 圖表可以使用前面概述的鏡像管理和分發(fā)技術(shù)拉取到隔離的環(huán)境中。
- 安全策略和合規(guī)性：安全和合規(guī)性問題通常是將 Kubernetes 部署到防火墻環(huán)境中的主要原因。醫(yī)療保健和金融等行業(yè)需要嚴(yán)格遵守 HIPAA 和 PCI-DSS 等法規(guī)，這些法規(guī)要求使用安全的環(huán)境，并限制對敏感數(shù)據(jù)的訪問。
解決方案：Kubernetes 的原生功能，例如 Pod 安全策略 (PSP)、基于角色的訪問控制 (RBAC) 和網(wǎng)絡(luò)策略，可以用來增強(qiáng)防火墻環(huán)境中 Kubernetes 集群的安全性。此外，部署像 Istio 這樣的服務(wù)網(wǎng)格或 Linkerd 可以提供細(xì)粒度的流量控制和安全性，確保只有授權(quán)的服務(wù)才能進(jìn)行通信。這些網(wǎng)格還提供雙向 TLS (mTLS) 用于加密微服務(wù)之間的流量，進(jìn)一步增強(qiáng)安全性并符合法規(guī)。
- 入口控制和負(fù)載均衡：在防火墻環(huán)境中，外部負(fù)載均衡服務(wù)（如 AWS ELB 或 GCP 負(fù)載均衡器）可能不可用，導(dǎo)致將流量路由到 Kubernetes 集群中運(yùn)行的服務(wù)變得困難。Kubernetes 的內(nèi)置 NodePort 類型服務(wù)不安全，因?yàn)樗鼈冃枰谒?Kubernetes 節(jié)點(diǎn)上打開一個(gè)非標(biāo)準(zhǔn)端口。每個(gè)需要在集群外部公開的服務(wù)都需要一個(gè)單獨(dú)的 NodePort 服務(wù)，從而使防火墻管理變得復(fù)雜。
解決方案：為了在集群外部公開服務(wù)，像 Istio 或 Contour 這樣的入口網(wǎng)關(guān)可以充當(dāng)代理，將流量路由到這些服務(wù)。它們保護(hù)對內(nèi)部服務(wù)的訪問，因?yàn)樗鼈兛梢越K止 TLS 流量并充當(dāng)所有需要公開的服務(wù)的單一入口點(diǎn)。
私有負(fù)載均衡解決方案，如 MetalLB，可以部署以提供入口網(wǎng)關(guān)的 IP/主機(jī)名的高可用性。使用 MetalLB 和入口網(wǎng)關(guān)的組合可以提高安全性。只有一個(gè) IP 地址/主機(jī)名需要保護(hù)，并且所有暴露服務(wù)的網(wǎng)絡(luò)流量都將被加密。
在防火墻環(huán)境中部署和管理 Kubernetes 會帶來獨(dú)特的挑戰(zhàn)，從鏡像管理和控制平面訪問到 DNS 解析和第三方集成。但是，通過正確的策略和工具，組織可以利用 Kubernetes 的強(qiáng)大功能，同時(shí)保持防火墻基礎(chǔ)設(shè)施所需的安全性、合規(guī)性和運(yùn)營穩(wěn)定性。容器注冊表鏡像復(fù)制、特定查詢的 DNS 轉(zhuǎn)發(fā)、VPN 隧道、入口網(wǎng)關(guān)和自托管監(jiān)控工具等技術(shù)確保 Kubernetes 即使在最受限制的環(huán)境中仍然是一個(gè)可行的解決方案。
旨在采用云原生技術(shù)的組織必須仔細(xì)設(shè)計(jì)其基礎(chǔ)設(shè)施，確保滿足安全要求，而不會犧牲 Kubernetes 提供的可擴(kuò)展性和靈活性。通過利用上述解決方案，Kubernetes 集群即使在高度受限的環(huán)境中也能有效運(yùn)行。
