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