Consul中文文檔—Consul安全模型概覽

Consul 安全模型概覽

本篇文章翻譯自：https://www.consul.io/docs/security

本篇文章介紹下Consul安全模型概覽。

轉載請注明🙂，喜歡請一鍵三連哦😊

文章目錄

• Consul安全模型
• • 安全配置
  • • 已知非安全配置
  • 威脅模型
  • 外部威脅概覽
  • 網絡端口
• 參考文檔

Consul安全模型

Consul依靠輕量級的gossip機制和RPC系統來提供各種功能。這兩個系統都有不同的安全機制，這源于它們的設計。然而，Consul的安全機制有一個共同的目标：提供保密性、完整性和認證功能。

Gossip協定由Serf提供支援，它使用對稱密鑰或共享秘密的密碼系統。這裡有更多關于Serf安全性的細節。關于如何在Consul中啟用Serf的gossip加密的細節，請看這裡的文檔。

RPC系統支援使用端到端TLS，并可選擇用戶端認證。TLS是一種廣泛部署的非對稱加密系統，是Web上安全的基礎。

這意味着Consul的通信是受保護的，可以防止竊聽，篡改和欺騙。這使得Consul可以在不受信任的網絡上運作，如EC2和其他共享主機提供商。

安全配置

Consul威脅模型隻适用于Consul在安全配置下運作的情況。在預設安全配置下不會運作。如果下面的任何設定沒有啟用，那麼這個威脅模型的部分内容将不會生效。對于Consul威脅模型之外的項目，還必須采取額外的安全預防措施，如下文各節所述。

• Consul的運作就像任何其他二進制檔案一樣。Consul作為一個單一的程序運作，并遵守與您系統上任何其他應用程式相同的安全要求。Consul不會與主機系統互動，以任何方式改變或操縱安全參數。根據您的作業系統，采取您通常對單個程序采取的任何預防措施或補救步驟。下文概述了一些您可以采取的修複步驟示例。
  • 以非root使用者的身份運作應用程式，包括Consul，并進行适當的配置。
  • 使用核心安全子產品（如SELinux）實作強制通路控制。
  • 防止無權使用者成為root使用者。
• 啟用ACLs(預設拒絕)。必須将Consul配置為使用允許清單（預設拒絕）方式的ACL。這将迫使所有請求具有明确的匿名通路或提供ACL令牌。
• 啟用加密。必須啟用并配置TCP和UDP加密，以防止Consul代理之間的明文通信。至少應該啟用

  verify_outgoing

  ，以驗證伺服器的真實性，每個伺服器都有一個唯一的TLS證書。

  verify_server_hostname

  也是必需的，以防止被入侵的代理重新啟動為伺服器，并獲得所有密鑰。

  verify_incoming

  通過互相認證提供了額外的代理驗證，但并不是嚴格意義上強制執行威脅模型所必需的，因為請求也必須包含有效的ACL令牌。微妙的是，目前

  verify_incoming = false

  将允許伺服器仍然接受來自用戶端的未加密連接配接（以允許逐漸推出TLS）。這本身并不違反威脅模型，但任何選擇不使用TLS的錯誤配置的用戶端都會違反模型。我們建議将此設定為true。如果将其設定為false，則必須注意確定所有的consul用戶端使用

  verify_outgoing = true

  ，如上所述，但同時所有外部API/UI通路必須通過HTTPS，并禁用HTTP監聽器。

已知非安全配置

除了配置上述非預設設定外，Consul還有幾個非預設選項可能會帶來額外的安全風險。

• 啟用網絡暴露的API的腳本檢查。如果Consul代理（Client或Server模式）将其HTTP API暴露在localhost以外的網絡上，

  enable_script_checks

  必須為false，否則，即使配置了ACL，腳本檢查也會帶來遠端代碼執行的威脅。如果HTTP API必須暴露，

  enable_local_script_checks

  提供了一個安全的替代方案，并且從1.3.0開始就可以使用。這個功能也被回移植到0.9.4、1.1.1和1.2.4更新檔版本中，如這裡所述。
• 啟用遠端執行。Consul 包含了一個

  consul exec

  功能，允許跨叢集執行任意指令。從0.8.0開始，這個功能預設是禁用的。我們建議将其禁用。如果啟用，必須非常小心，以確定正确的ACL限制通路，例如，任何管理令牌授予在叢集上執行任意代碼的通路權限。
• 驗證伺服器主機名單獨使用。從0.5.1版本到1.4.0版本，我們記錄了

  verify_server_hostname

  為

  true

  意味着

  verify_outgoing

  ，但是由于一個bug，情況并非如此，是以隻設定

  verify_server_hostname

  會導緻用戶端和伺服器之間的純文字通信。更多細節請參見CVE-2018-19653。這個問題在1.4.1中得到了修複。

威脅模型

以下是Consul威脅模型的部分内容。

• Consul Agent與Agent之間的通信。Consul代理之間的通信應該是安全的，不會被竊聽。這需要在叢集上啟用傳輸加密，并涵蓋TCP和UDP流量。
• Consul Agent到CA的通信。Consul Server與為Connect配置的證書授權提供商之間的通信始終是加密的。
• 傳輸中的資料被篡改。任何篡改都應該可以檢測到，并導緻Consul避免處理請求。
• 未經認證或授權而通路資料。所有請求必須經過認證和授權。這需要在叢集上啟用ACL，并采用預設的拒絕模式。
• 惡意消息導緻的狀态修改或損壞。不良格式的消息會被丢棄，格式良好的消息需要認證和授權。
• 非伺服器成員通路原始資料。所有伺服器必須加入群集（具有适當的身份驗證和授權）才能開始參與Raft。Raft資料是通過TLS傳輸的。
• 針對節點的拒絕服務。針對節點的DoS攻擊不應損害軟體的安全立場。
• 基于Connect的服務對服務通信。兩個支援Connect的服務之間的通信（原生或代理）應該是安全的，可以防止竊聽并提供認證。這是通過互相的TLS實作的。

以下不屬于Consul Server Agent的Consul威脅模型。

• 通路（讀或寫）Consul資料目錄。所有Consul Server，包括Non-Leaders，都會将Consul的全套狀态持久化到這個目錄(catalog)中。資料包括所有KV、服務注冊、ACL令牌、Connect CA配置等。對這個目錄的任何讀寫都允許攻擊者通路和篡改這些資料。
• 通路（讀或寫）Consul配置Catalog。Consul配置可以啟用或禁用ACL系統，修改資料目錄路徑等。對該目錄的任何讀或寫都允許攻擊者重新配置Consul的許多方面。通過禁用ACL系統，可能會讓攻擊者通路所有Consul資料。
• 對運作中的Consul Server Agent的記憶體通路。如果攻擊者能夠檢查正在運作的Consul伺服器代理的記憶體狀态，幾乎所有Consul資料的保密性都可能被破壞。如果你使用的是外部的Connect CA，Consul程序永遠無法獲得根私鑰材料，可以認為是安全的。服務Connect TLS證書應該被認為是妥協的；它們從不被伺服器代理持久化，但至少在Sign請求的持續時間内确實存在于記憶體中。

以下不屬于Consul用戶端代理的Consul威脅模型。

• 通路（讀或寫）Consul資料目錄。Consul用戶端将使用資料目錄來快取區域狀态。這包括本地服務、相關ACL令牌、Connect TLS證書等。對該目錄的讀或寫通路将允許攻擊者通路這些資料。這些資料通常是叢集完整資料的一個較小的子集。
• 通路（讀或寫）Consul配置目錄。Consul用戶端配置檔案包含服務的位址和端口資訊、代理的預設ACL令牌等。通路Consul配置可以使攻擊者将服務的端口改為惡意端口，注冊新的服務等。此外，一些服務定義還附加了ACL令牌，可以在整個叢集範圍内用來冒充該服務。攻擊者無法改變叢集範圍内的配置，如禁用ACL系統。
• 對運作中的Consul用戶端代理進行記憶體通路。這一點的爆炸半徑比伺服器代理小得多，但資料子集的保密性還是會被洩露。特别是針對代理的API請求的任何資料，包括服務、KV和連接配接資訊都可能被洩露。如果伺服器上的某一組資料從未被代理請求過，那麼它永遠不會進入代理的記憶體，因為複制隻存在于伺服器之間。攻擊者也有可能提取用于在該代理上注冊服務的ACL令牌，因為這些令牌必須與注冊服務一起存儲在記憶體中。
• 對本地Connect代理或服務的網絡通路。服務與 Connect 感覺的代理之間的通信通常是未加密的，必須通過受信任的網絡進行。這通常是一個環回裝置。這就要求同一台機器上的其他程序是受信任的，或者使用更複雜的隔離機制，如網絡命名空間。這也要求外部程序不能與Connect服務或代理進行通信（除了入站端口）。是以，非本地的Connect應用應該隻綁定到非公共位址。
• 不正确執行的Connect代理或服務。Connect Proxy或本機內建服務必須正确地提供有效的葉子證書，驗證入站 TLS 用戶端證書，并調用 Consul 代理-本地授權端點。如果其中任何一項沒有正确執行，代理或服務可能允許未經認證或未經授權的連接配接。

外部威脅概覽

影響Consul威脅模型的有四個元件：Server Agent、Client Agent、Connect CA和Consul API用戶端（包括Connect的代理）。

Server Agent通過Raft協定參與上司者選舉和資料複制。與其他代理的所有通信都是加密的。資料在靜止時未加密地存儲在配置的資料目錄中。存儲的資料包括ACL令牌和TLS證書。如果 Connect 使用内置 CA，根證書私鑰也會存儲在磁盤上。外部CA提供商不在此目錄中存儲資料。這個資料目錄必須小心保護，以防止攻擊者冒充伺服器或特定ACL使用者。我們計劃随着時間的推移，對資料目錄引入進一步的緩解措施（至少包括部分資料加密），但資料目錄應始終被視為秘密。

用戶端代理要加入叢集，必須提供具有節點寫能力的有效ACL令牌。Client和 Server代理之間的加入請求和所有其他API請求都通過TLS進行通信。用戶端服務于Consul API，并通過共享的TLS連接配接将所有請求轉發給Server Agent。每個請求都包含一個ACL令牌，用于認證和授權。沒有提供ACL令牌的請求将繼承Agent配置的預設ACL令牌。

Connect CA提供商負責存儲用于簽署和驗證通過Connect建立的連接配接的根（或中間）證書的私鑰。Consul伺服器代理通過加密方法與CA提供者通信。這種方法取決于所使用的CA提供者。Consul提供了一個内置的CA，它在Server Agent的本地執行所有操作。除了内置CA，Consul本身不存儲任何私鑰資訊。

Consul API用戶端（代理本身、内置UI、外部軟體）必須通過TLS與Consul代理進行通信，并且每次請求都必須提供一個ACL令牌進行認證和授權。

網絡端口

關于配置網絡規則以支援Consul，請參見Ports Used，檢視Consul使用的網絡端口清單，以及它們用于哪些功能的詳細資訊。

參考文檔

• Consul中文文檔
• Consul安全模型