關於 Kubernetes 最受歡迎的套件管理器的故事的本質可以用表情符號來描述：
- 盒子是 Helm（這是最接近最新 Emoji 版本的東西）；
- 鎖——安全；
- 小人物就是問題的解決方案。
事實上，一切都會有點複雜，而且故事充滿了關於的技術細節 如何確保 Helm 安全.
- 簡單介紹一下 Helm 是什麼，以防您不知道或忘記。 它解決什麼問題以及它在生態系統中的位置。
- 我們來看看 Helm 架構。 如果不了解組件的架構，關於安全性以及如何使工具或解決方案更安全的討論是不完整的。
- 讓我們討論 Helm 組件。
- 最迫切的問題是未來——Helm 3 的新版本。
本文中的所有內容均適用於 Helm 2。該版本目前正在生產中，很可能是您目前使用的版本，並且它是包含安全風險的版本。
關於音箱： 亞歷山大·卡約羅夫（）已開發10年，協助完善內容 並加入委員會 。 現在，他在 Chainstack 擔任開發主管 - 這是開發經理和負責交付最終版本的人員之間的混合。 也就是說，它位於戰場上，從產品的創造到操作的一切都發生在戰場上。
Chainstack 是一家小型、積極發展的新創公司，其使命是讓客戶忘記運行去中心化應用程式的基礎設施和複雜性；開發團隊位於新加坡。 不要要求 Chainstack 出售或購買加密貨幣，而是提出談論企業區塊鏈框架，他們會很樂意回答你。
舵
這是 Kubernetes 的套件（圖表）管理器。 將應用程式引入 Kubernetes 叢集的最直觀、最通用的方式。
當然，我們談論的是一種比創建自己的 YAML 清單和編寫小型實用程式更具結構性和工業性的方法。
Helm 是目前可用且流行的最好的。
為什麼是頭盔？ 主要是因為它得到 CNCF 的支持。 Cloud Native 是一個大型組織，也是 Kubernetes、etcd、Fluentd 等專案的母公司。
另一個重要的事實是 Helm 是一個非常受歡迎的項目。 當我在 2019 年 12 月開始談論如何確保 Helm 安全時，該專案在 GitHub 上有一千顆星。 到 XNUMX 月，人數已達 XNUMX 人。
許多人對 Helm 感興趣，因此即使您尚未使用它，了解它的安全性也會讓您受益匪淺。 安全很重要。
Helm 核心團隊由 Microsoft Azure 支持，因此是一個相當穩定的項目，與許多其他項目不同。 3 月中旬 Helm 2 Alpha XNUMX 的發布表明，有相當多的人在從事該項目，他們有開發和改進 Helm 的願望和精力。
Helm 解決了 Kubernetes 中應用程式管理的幾個根本問題。
- 應用程式包裝。 即使像 WordPress 上的「Hello, World」這樣的應用程式也已經包含多個服務，並且您希望將它們打包在一起。
- 管理管理這些應用程式所帶來的複雜性。
- 應用程式安裝或部署後不會結束的生命週期。 它繼續存在，需要更新，Helm 會為此提供幫助，並嘗試為此採取正確的措施和政策。
套袋 它的組織方式清晰：元資料完全按照 Linux、Windows 或 MacOS 的常規套件管理器的工作方式進行。 即儲存庫、各種套件的依賴關係、應用程式的元資訊、設定、配置功能、資訊索引等。Helm 允許您為應用程式取得和使用所有這些。
複雜性管理。 如果您有許多相同類型的應用程序，則需要參數化。 模板由此而來，但為了避免必須想出自己的創建模板的方式，您可以使用 Helm 提供的開箱即用的功能。
應用程式生命週期管理 - 在我看來，這是最有趣且尚未解決的問題。 這就是我當時來到 Helm 的原因。 我們需要專注於應用程式生命週期，並希望將我們的 CI/CD 和應用程式週期轉移到這個範例。
Helm 允許您：
- 管理部署，引入配置和修訂的概念；
- 成功執行回滾；
- 對不同的事件使用鉤子；
- 添加額外的應用程式檢查並對其結果做出回應。
而且 安全帽有“電池” - 大量美味的東西可以以插件的形式包含在內，簡化您的生活。 插件可以獨立編寫，它們相當孤立，不需要和諧的架構。 如果您想實現某些功能，我建議將其作為插件進行，然後可能將其包含在上游中。
Helm 是基於三個主要概念：
- 圖表回購 — 您的清單可能的描述和參數化陣列。
- 配置 ——即將套用的值（文字、數值等）。
- 發行 收集上面的兩個元件，一起變成Release。 可以對版本進行版本控制，從而實現有組織的生命週期：安裝時較小，升級、降級或回滾時較大。
舵架構
該圖概念性地描述了 Helm 的高階架構。
讓我提醒您一下，Helm 是與 Kubernetes 相關的東西。 因此，我們離不開 Kubernetes 叢集（矩形）。 kube-apiserver 元件駐留在 master 上。 沒有 Helm，我們就有 Kubeconfig。 Helm 帶來了一個小型二進位檔案（如果您可以稱之為 Helm CLI 實用程式），它可以安裝在電腦、筆記型電腦、大型主機等任何裝置上。
但這還不夠。 Helm 有一個名為 Tiller 的伺服器元件。 它代表 Helm 在叢集內的利益；它是 Kubernetes 叢集內的一個應用程序，就像任何其他應用程式一樣。
Chart Repo 的下一個元件是包含圖表的儲存庫。 有官方的倉庫，也可能有公司或專案的私人倉庫。
相互作用
讓我們看看當我們想要使用 Helm 安裝應用程式時，架構元件如何互動。
- 我們在說話
Helm install，存取儲存庫（Chart Repo）並取得 Helm Chart。
- Helm 實用程式 (Helm CLI) 與 Kubeconfig 交互，以確定要聯絡哪個叢集。
- 收到此資訊後，該實用程式將位於我們叢集中的 Tiller 作為應用程式引用。
- Tiller 呼叫 Kube-apiserver 在 Kubernetes 中執行操作，建立一些物件（服務、pod、副本、機密等）。
接下來，我們將使圖表變得複雜，以查看整個 Helm 架構作為一個整體可能面臨的攻擊向量。 然後我們會盡力保護她。
攻擊向量
第一個潛在的弱點是 特權API - 用戶。 作為該計劃的一部分，這名駭客獲得了 Helm CLI 的管理員存取權限。
非特權 API 用戶 如果它在附近的某個地方，也可能造成危險。 這樣的使用者將有不同的上下文，例如，他可以在 Kubeconfig 設定中固定在一個叢集命名空間中。
最有趣的攻擊向量可能是駐留在 Tiller 附近的叢集中並且可以存取它的進程。 這可以是查看叢集網路環境的 Web 伺服器或微服務。
Chart Repo 是一種奇特但越來越流行的攻擊變體。 無良作者創建的圖表可能包含不安全的資源，您只要相信它就會完成它。 或者它可以替換您從官方儲存庫下載的圖表，例如以策略的形式建立資源並升級其存取權限。
讓我們試著抵禦這四個面向的攻擊，並找出 Helm 架構中哪些地方有問題，哪些地方可能沒有問題。
讓我們放大圖表，添加更多元素，但保留所有基本組件。
Helm CLI 與 Chart Repo 通信，與 Kubeconfig 交互，並將工作轉移到叢集的 Tiller 元件上。
Tiller 由兩個物件表示：
- Tiller-deploy svc，揭露某個服務；
- Tiller-deploy pod（圖中為一個副本中的單一副本），整個負載在其上運行，存取叢集。
使用不同的協定和方案進行互動。 從安全角度來看，我們最感興趣的是：
- Helm CLI 存取圖表儲存庫的機制：什麼協定、是否有身份驗證以及可以用它做什麼。
- 使用 kubectl 的 Helm CLI 與 Tiller 通訊所採用的協定。 這是安裝在叢集內的 RPC 伺服器。
- Tiller 本身可供駐留在叢集中的微服務存取並與 Kube-apiserver 互動。
讓我們按順序討論所有這些領域。
紅十字會
除非啟用 RBAC，否則討論 Helm 或叢集內任何其他服務的任何安全性都是沒有意義的。
看起來這不是最新的推薦，但我確信很多人即使在生產中仍然沒有啟用 RBAC，因為它很麻煩，需要配置很多東西。 不過，我鼓勵您這麼做。
— RBAC 網站律師。 它包含大量有趣的材料，可幫助您設定 RBAC、展示其優點以及如何在生產中基本使用它。
我將嘗試解釋 Tiller 和 RBAC 的工作原理。 Tiller 在叢集內的某個服務帳戶下工作。 通常，如果未配置 RBAC，則這將是超級使用者。 在基本配置中，Tiller 將是管理員。 這就是為什麼人們常說 Tiller 是通往集群的 SSH 隧道。 事實上，確實如此，因此您可以使用單獨的專用服務帳戶來取代上圖中的預設服務帳戶。
當您初始化 Helm 並將其首次安裝在伺服器上時，您可以使用以下命令設定服務帳戶 --service-account。 這將允許您使用具有所需的最低權限集的使用者。 確實，您必須創建這樣一個“花環”：Role 和 RoleBinding。
不幸的是，Helm 不會為你做這件事。 您或您的 Kubernetes 叢集管理員需要事先為 service-account 準備一組 Roles 和 RoleBindings，以便透過 Helm。
問題出現了——Role 和 ClusterRole 之間有什麼區別？ 不同之處在於 ClusterRole 適用於所有命名空間，這與常規 Role 和 RoleBindings 不同，後者僅適用於專門的命名空間。 您可以為整個叢集和所有命名空間配置策略，也可以為每個命名空間單獨配置策略。
值得一提的是，RBAC解決了另一個大問題。 許多人抱怨 Helm 不幸的是不是多租戶（不支援多租戶）。 如果多個團隊使用一個叢集並使用 Helm，基本上不可能在這個叢集內設定策略並限制他們的訪問，因為 Helm 運行在某個服務帳戶下，並且它從該服務帳戶下建立叢集中的所有資源，這有時非常不方便。 這是真的——就像二進位檔案本身一樣，進程也一樣， Helm Tiller 沒有多租戶概念.
然而，有一個很好的方法可以讓您在叢集中多次執行 Tiller。 這沒有問題，Tiller 可以在每個命名空間中啟動。 因此，您可以使用 RBAC、Kubeconfig 作為上下文，並限制對特殊 Helm 的存取。
它看起來像這樣。
例如，有兩個具有不同團隊（兩個命名空間）上下文的 Kubeconfig：X Team 用於開發團隊和管理叢集。 管理員叢集有自己的寬 Tiller，它位於 Kube-system 命名空間中，是一個對應的高階服務帳戶。 並為開發團隊提供單獨的命名空間，他們將能夠將他們的服務部署到特殊的命名空間。
這是一個可行的方法，Tiller 不太耗電，不會大大影響您的預算。 這是快速解決方案之一。
您可以隨意單獨配置Tiller，並為Kubeconfig 提供團隊、特定開發人員或環境的上下文：開發、暫存、生產（令人懷疑的是，所有內容都將位於同一個叢集上，但是，這是可以完成的）。
繼續我們的故事，讓我們從 RBAC 轉向 ConfigMap。
配置映射
Helm 使用 ConfigMaps 作為其資料儲存。 當我們談論架構時，沒有任何資料庫可以儲存有關發布、配置、回滾等資訊。ConfigMaps 用於此目的。
ConfigMap 的主要問題是眾所周知的——原則上它們是不安全的； 不可能儲存敏感數據。 我們談論的是不應該超出服務範圍的一切，例如密碼。 目前 Helm 最原生的方式是從使用 ConfigMap 切換到使用 Secret。
這樣做非常簡單。 覆蓋 Tiller 設定並指定儲存為機密。 然後，對於每個部署，您將收到的不是 ConfigMap，而是一個秘密。
你可能會說秘密本身就是一個奇怪的概念，而且不太安全。 然而，值得理解的是，Kubernetes 開發人員自己正在這樣做。 從1.10版本開始，即在相當長的一段時間裡，至少在公有雲中，連接正確的儲存來儲存秘密是可能的。 該團隊目前正在研究如何更好地分配對機密、單一 Pod 或其他實體的存取權限。
最好將存儲頭盔轉移到秘密中，而它們反過來又受到集中保護。
當然會保留 資料儲存限制為 1 MB。 Helm 這裡使用 etcd 作為 ConfigMap 的分散式儲存。 他們認為這是一個適合複製等的資料塊。 Reddit 上有一個關於此問題的有趣討論，我建議在周末找到這篇有趣的讀物或閱讀摘錄 .
圖表回購
圖表是社會上最脆弱的，可能成為「中間人」的來源，特別是如果您使用庫存解決方案。 首先，我們討論的是透過 HTTP 公開的儲存庫。
您肯定需要透過 HTTPS 公開 Helm Repo - 這是最好的選擇，而且價格便宜。
注意 圖表簽名機制。 這項技術非常簡單。 這與您在 GitHub 上使用的東西相同，這是一個帶有公鑰和私鑰的常規 PGP 機器。 設定並確保擁有必要的密鑰並簽署所有內容，這確實是您的圖表。
另外， Helm 用戶端支援 TLS （不是伺服器端 HTTP 意義上的，而是雙向 TLS 的）。 您可以使用伺服器和客戶端密鑰進行通訊。 老實說，我不使用這樣的機制，因為我不喜歡相互證書。 基本上， - 用於為 Helm 2 設定 Helm Repo 的主要工具 - 也支援基本驗證。 如果更方便、更安靜，您可以使用基本身份驗證。
還有一個插件 ，它允許您在 Google Cloud Storage 上託管 Chart Repos。 這非常方便，效果很好並且非常安全，因為所有描述的機制都是回收的。
如果您啟用 HTTPS 或 TLS、使用 mTLS 並啟用基本驗證以進一步降低風險，您將獲得與 Helm CLI 和 Chart Repo 的安全通訊通道。
gRPC API
下一步非常重要 - 確保 Tiller 的安全，它位於叢集中，一方面是伺服器，另一方面，它本身會存取其他元件並試圖冒充某人。
正如我已經說過的，Tiller 是一個公開 gRPC 的服務，Helm 用戶端透過 gRPC 存取它。 當然，預設情況下 TLS 是禁用的。 為什麼這樣做是一個有爭議的問題，在我看來，一開始就簡化了設定。
對於生產甚至登台，我建議在 gRPC 上啟用 TLS。
在我看來，與圖表的 mTLS 不同，這裡是合適的，並且完成得非常簡單 - 生成 PQI 基礎設施、建立憑證、啟動 Tiller、在初始化期間傳輸憑證。 之後，您可以執行所有 Helm 命令，向自己展示產生的憑證和私鑰。
這樣您就可以保護自己免受叢集外部向 Tiller 發出的所有請求的影響。
因此，我們已經保護了 Tiller 的連線通道，我們已經討論了 RBAC 並調整了 Kubernetes apiserver 的權限，減少了它可以互動的網域。
防護頭盔
讓我們看一下最終的圖表。 這是具有相同箭頭的相同架構。
現在可以安全地將所有連接繪製為綠色：
- 對於 Chart Repo，我們使用 TLS 或 mTLS 和基本驗證；
- Tiller 的 mTLS，它作為帶有 TLS 的 gRPC 服務公開，我們使用憑證；
- 叢集使用具有 Role 和 RoleBinding 的特殊服務帳戶。
我們已經顯著保護了叢集的安全，但有人聰明地說：
“只有一種絕對安全的解決方案——一台關閉的計算機，位於一個混凝土盒子裡，並由士兵看守。”
有多種方法可以操縱資料並尋找新的攻擊向量。 然而，我相信這些建議將達到基本的產業安全標準。
獎金
這部分與安全性沒有直接關係，但也很有用。 我將向您展示一些很少有人知道的有趣的事情。 例如，如何搜尋圖表 - 官方和非官方。
在儲存庫中 現在大約有 300 個圖表和兩個串流：穩定版和孵化器。 任何做出貢獻的人都非常清楚從孵化器到馬厩是多麼困難，以及飛出馬厩是多麼容易。 然而，這並不是搜尋 Prometheus 圖表以及您喜歡的任何其他內容的最佳工具，原因很簡單 - 它不是一個可以方便地搜尋軟體包的入口網站。
但有一個服務 ，這使得尋找圖表更加方便。 最重要的是，還有更多的外部儲存庫和近 800 個可用的超級按鈕。 另外，如果您因為某些原因不想將圖表傳送到穩定版，您可以連接您的儲存庫。
試試 hub.helm.sh，讓我們一起開發它。 該服務位於Helm專案下，如果你是前端開發人員並且只想改善外觀，你甚至可以為其UI做出貢獻。
我還想提請您注意 開放 Service Broker API 集成。 聽起來很麻煩、不清楚，但卻解決了每個人都面臨的問題。 讓我用一個簡單的例子來解釋。
有一個 Kubernetes 集群，我們要在其中運行一個經典應用程式 - WordPress。 一般來說，完整的功能需要資料庫。 有許多不同的解決方案，例如，您可以啟動自己的有狀態服務。 這不是很方便，但很多人都這樣做。
其他人，像我們 Chainstack，使用 MySQL 或 PostgreSQL 等託管資料庫作為他們的伺服器。 這就是為什麼我們的資料庫位於雲端中的某個位置。
但是出現了一個問題：我們需要將我們的服務與資料庫連接，創建資料庫風格，傳輸憑證並以某種方式管理它。 所有這些通常由系統管理員或開發人員手動完成。 而且應用少的時候也沒問題。 當它們很多時，您需要聯合收割機。 有這樣一個收割機——它就是Service Broker。 它允許您使用公有雲叢集的特殊插件，並透過 Broker 從提供者訂購資源，就像 API 一樣。 為此，您可以使用本機 Kubernetes 工具。
這很簡單。 例如，您可以使用基礎層（可以設定）查詢 Azure 中的託管 MySQL。 使用 Azure API，將建立資料庫並準備使用。 您無需幹預此操作，插件負責此操作。 例如，OSBA（Azure 外掛程式）將向服務傳回憑證並將其傳遞給 Helm。 您將能夠將 WordPress 與雲端 MySQL 結合使用，完全不處理託管資料庫，也不用擔心內部的有狀態服務。
可以說，Helm 充當了黏合劑的角色，一方面允許您部署服務，另一方面消耗雲端提供者的資源。
您可以編寫自己的插件並在本地使用整個故事。 然後，您將擁有自己的企業雲端提供者外掛程式。 我建議嘗試這種方法，特別是如果您規模較大並且想要快速部署某個功能的開發、登台或整個基礎架構。 這將使您的營運或 DevOps 變得更加輕鬆。
我已經提到的另一個發現是 helm-gcs 插件，它允許您使用 Google-buckets（物件儲存）來儲存 Helm 圖表。
您只需要四個指令即可開始使用它：
- 安裝插件；
- 發起它；
- 設定儲存桶的路徑，該路徑位於gcp中；
- 以標準方式發布圖表。
美妙之處在於將使用本機 gcp 方法進行授權。 您可以使用服務帳戶、開發人員帳戶，無論您想要什麼。 非常方便，而且無需任何操作費用。 如果你像我一樣提倡 opsless 哲學，那麼這將非常方便，特別是對於小型團隊。
替代品
Helm 並不是唯一的服務管理解決方案。 關於它有很多疑問，這可能是第三個版本出現得如此之快的原因。 當然還有其他選擇。
這些可以是專門的解決方案，例如 Ksonnet 或 Metaarticle。 您可以使用經典的基礎架構管理工具（Ansible、Terraform、Chef 等）來實現我談到的相同目的。
終於有解決方法了 ，其受歡迎程度正在不斷增長。
Operator Framework 是最值得考慮的 Helm 替代方案。
它更原生於 CNCF 和 Kubernetes， 但進入門檻要高得多，您需要更多地編程並更少地描述清單。
有各種插件，例如 Draft、Scaffold。 它們讓生活變得更加輕鬆，例如，它們簡化了開發人員部署測試環境的發送和啟動 Helm 的周期。 我稱他們為賦能者。
這是所有東西所在位置的可視化圖表。
x 軸是您對正在發生的事情的個人控制級別，y 軸是 Kubernetes 的原生級別。 Helm 版本 2 處於中間位置。 在版本 3 中，雖然不是很大，但控制和原生水平都提高了。 Ksonnet 等級的解決方案甚至仍然不如 Helm 2。但是，它們值得一看，以了解這個世界上還有什麼。 當然，您的設定管理員將在您的控制之下，但它絕對不是 Kubernetes 原生的。
Operator Framework 絕對是 Kubernetes 原生的，讓您可以更優雅、更謹慎地管理它（但請記住入門級別）。 相反，這適用於專門的應用程式並為其創建管理，而不是使用 Helm 打包大量應用程式的大規模收割機。
擴展器只是稍微改善控制、補充工作流程或在 CI/CD 管道上走捷徑。
頭盔的未來
好消息是Helm 3來了，Helm 3.0.0-alpha.2的alpha版本已經發布了，大家可以試試看。 它相當穩定，但功能仍然有限。
為什麼需要 Helm 3？ 首先，這是一個關於 蒂勒失踪，作為一個組件。 正如您已經了解的那樣，這是向前邁出的一大步，因為從架構安全性的角度來看，一切都被簡化了。
當 Helm 2 創建時，也就是 Kubernetes 1.8 左右甚至更早的時候，許多概念還不成熟。 例如CRD理念現在積極落地，Helm將 使用CRD來儲存結構。 可以只使用客戶端而不維護伺服器部分。 因此，請使用本機 Kubernetes 指令來處理結構和資源。 這是向前邁出的一大步。
會出現 支援本機 OCI 儲存庫 （開放容器倡議）。 這是一項巨大的舉措，Helm 感興趣主要是為了發布其圖表。 例如，Docker Hub 支援許多 OCI 標準。 我並不是猜測，但也許經典的 Docker 儲存庫提供者將開始為您提供託管 Helm 圖表的機會。
對我來說有爭議的故事是 盧阿支持，作為編寫腳本的模板引擎。 我不是 Lua 的忠實粉絲，但這將是一個完全可選的功能。 我檢查了 3 次 - 不需要使用 Lua。 因此，那些想要使用 Lua 的人，那些喜歡 Go 的人，加入我們龐大的陣營並為此使用 go-tmpl 。
最後，我絕對缺少的是 模式出現和資料類型驗證。 int 或 string 不會再有問題，不需要用雙引號將零括起來。 將出現一個 JSONS 架構，讓您明確描述值。
將會大量返工 事件驅動模型。 已經在概念上描述了它。 查看 Helm 3 分支，您將看到添加了多少事件和鉤子以及其他內容，這將大大簡化，另一方面，增加對部署過程及其反應的控制。
Helm 3 會更簡單、更安全、更有趣，不是因為我們不喜歡 Helm 2，而是因為 Kubernetes 正在變得更先進。 相應地，Helm可以利用Kubernetes的發展，並在其上為Kubernetes創建優秀的管理器。
另一個好消息是 亞歷山大·卡約羅夫會告訴你， 讓我們提醒您，開發、測試和營運流程整合會議將在莫斯科舉行 30月1日及XNUMX月XNUMX日。 20 月 XNUMX 日之前您仍然可以這樣做 並告訴我們您對解決方案的體驗 DevOps 方法的任務。
關注會議檢查點和新聞 и .
來源： www.habr.com