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