概念

歡迎來到 KES 文件網站。這些頁面提供了 KES 如何運作的高階概述、有關 KES 組件、一般架構和存取控制的資訊。

如需設定 KES 的更詳細文件，請參閱設定指南。

考慮一個基本設定，其中包含一個應用程式實例和一個 KES 伺服器。

應用程式透過 TLS 連接至 KES 伺服器。然後，應用程式使用 KES 伺服器 API 來執行諸如建立新的加密金鑰等操作。KES 伺服器與中央金鑰管理系統 (KMS) 通訊。

中央 KMS 包含所有狀態資訊，包括加密金鑰。對於任何有狀態的操作，例如建立加密主金鑰，KES 伺服器會連線到 KMS。

KES 伺服器直接處理無狀態操作，例如產生新的資料加密金鑰 (DEK)，無需與中央 KMS 互動。由於大多數金鑰管理操作都是無狀態的，因此 KES 伺服器會處理負載，包括加密、解密和金鑰推導的操作。

較大的工作負載需要較多的資源，因此需要更多應用程式實例。如果所有這些實例都直接與傳統的 KMS 通訊，例如專用的伺服器或硬體設備，它們最終會超出 KMS 的能力。

Kubernetes 會根據目前的工作負載自動新增或移除資源。但是，設計用於保護加密金鑰的硬體安全設備通常無法自動擴展。對於支援叢集的設備，擴展意味著購買更昂貴的硬體。

相比之下，KES 會隨著應用程式水平擴展。

KES 伺服器將應用程式與 KMS/金鑰儲存區分離，並且可以自行處理幾乎所有應用程式請求。它僅在建立或刪除加密金鑰時才必須與金鑰儲存區通訊。

同樣，KES 伺服器僅使用 KMS 來加密或解密儲存在金鑰儲存區或從金鑰儲存區提取的加密金鑰。因此，KES 伺服器將 KMS/金鑰儲存區上的負載減少了數個數量級。

一般而言，所有 KES 伺服器操作都需要驗證和授權。但是，KES 對兩者都使用相同的應用程式獨立機制：相互 TLS 驗證 (mTLS)。

KES 用戶端需要一個私鑰/公鑰對和一個 X.509 憑證。在以下章節中，我們將明確區分公鑰和憑證，以說明驗證和授權的運作方式。

KES 依賴相互 TLS (mTLS) 進行驗證。KES 用戶端和 KES 伺服器都需要各自的私鑰/憑證對。

預設情況下，每個 mTLS 對等方都必須信任該對等方憑證的發行者。這表示用戶端必須信任伺服器憑證的發行者，並且伺服器必須信任用戶端憑證的發行者。如果同一個授權單位同時發行用戶端的憑證和伺服器的憑證，則用戶端和伺服器各自都只需信任單一實體。如果不同的授權單位發行用戶端的憑證和伺服器的憑證，則用戶端和伺服器各自都必須信任這兩個授權單位。

透過 Extended Key Usage 擴充功能，憑證會描述特定公鑰的有效使用案例。在 mTLS 的情況下，用戶端憑證必須具有包含 Client Authentication 的擴充金鑰用途。同樣地，伺服器憑證必須具有包含 Server Authentication 的擴充金鑰用途。如果您的設定不如預期般運作，請檢查憑證是否包含正確的擴充金鑰用途值。

openssl x509 -noout -text -in <your-certificate.cert>

一般而言，KES 伺服器僅接受來自在 TLS 交握期間可以提供有效且經過驗證的 TLS 憑證 (📜) 的用戶端的 TLS 連線。

• 有效憑證表示憑證格式良好且未過期。
• 經過驗證的憑證表示 KES 信任簽署並發行該憑證的憑證授權單位。

當 KES 用戶端嘗試建立與 KES 伺服器的連線時，TLS 通訊協定會檢查以下內容

• KES 用戶端具有與用戶端提供的憑證 (📜) 中的公鑰對應的私鑰 (🗝️)。
• 用戶端提供的憑證是由 KES 伺服器信任的憑證授權單位 (CA) 發行的。

如果 TLS 交握成功，則 KES 伺服器會將該請求視為已驗證。

在測試或開發期間，可以略過憑證驗證。

1. 使用 --auth=off 選項啟動 KES 伺服器。
2. 然後，用戶端仍然會提供憑證，但是伺服器不會驗證該憑證是否由受信任的 CA 發行。相反地，用戶端可以提供自我簽署的憑證。

在判斷請求的真實性之後，KES 伺服器會檢查用戶端是否已獲得執行所請求操作的授權。KES 依賴基於角色和原則的授權模型。授權檢查會將請求與關聯至用戶端的原則進行比較。

當 KES 伺服器收到經過驗證的用戶端請求時，它會使用用戶端的公鑰從用戶端憑證計算用戶端身分。計算身分後，KES 伺服器會檢查該身分是否具有關聯的命名原則。如果存在此類的身分-原則對應，則 KES 伺服器會驗證請求是否符合該原則。否則，伺服器會拒絕該請求。

KES 伺服器原則會決定是否允許用戶端請求。原則包含一組規則，這些規則定義在哪些資源上允許或拒絕哪些 API 操作。KES 使用專為人類可讀性和理解而設計的原則定義，而不是彈性。

一般而言，原則模式具有以下格式

/<API-version>/<API>/<operation>/[<argument0>/<argument1>/...]

例如

將每個允許/拒絕規則寫為 glob 模式。glob 模式允許單一規則符合整個類別的請求。

KES 伺服器會依如下方式評估原則

1. 評估所有拒絕模式。如果任何拒絕模式符合，則使用 prohibited by policy 錯誤拒絕請求。
2. 評估所有允許模式。如果至少一個允許模式符合，則 KES 會接受該請求。
3. 如果沒有允許模式符合，則使用 prohibited by policy 錯誤拒絕該請求。

讓我們看一下原則範例

policy:
  my-policy:
    allow:
    - /v1/metrics
    - /v1/key/create/my-key
    - /v1/key/generate/my-key*
    - /v1/key/decrypt/my-key*
    deny:
    - /v1/key/*/my-key-internal*

my-policy 包含四個允許規則和一個拒絕規則。

KES 會優先處理 deny 規則。my-policy 包含一個 deny 規則，會禁止所有名稱前綴為 my-key-internal 的資源（即金鑰）進行任何金鑰 API 操作 (key/*/)。如果客戶端使用名稱前綴為該字串的金鑰提交任何類型的 API 操作，KES 會禁止該操作。例如，在此策略下，KES 會拒絕下列任何操作

• /v1/key/create/my-key-internal
• /v1/key/generate/my-key-internal
• /v1/key/generate/my-key-internal2

如果請求不符合任何 deny 模式，KES 會根據 allow 規則評估該請求。

在 my-policy 的情況下，KES 允許策略下的請求建立名為 my-key 的金鑰。如果使用者嘗試建立名為 my-key2 或任何其他字元組合的金鑰，則請求會傳回 prohibited by policy 錯誤，因為沒有任何 allow 規則符合該請求。

當使用者請求產生新的資料加密金鑰 (DEK) 或解密已加密的 (DEK) 時，該策略允許任何名稱前綴為 my-key 的金鑰。KES 允許 /v1/key/generate/my-key 或 /v1/key/generate/my-key2，但禁止 /v1/key/generate/key-to-generate1。

• 有關策略和更多範例的詳細資訊，請參閱：策略設定
• 有關 KES 伺服器 API 的全面概述，請參閱：伺服器 API

策略-身分對應是一對多的關係，表示您可以將多個身分關聯到同一個策略。但是，您一次只能在 KES 伺服器上將一個身分關聯到一個策略。

多個 KES 伺服器可以各自擁有自己的策略-身分關係集合。例如，KES 伺服器 Server1 可以將身分 Ann 關聯到策略 Policy1，而 KES 伺服器 Server2 可以將相同身分 Ann 關聯到不同的策略 Policy2。
兩個 KES 伺服器 Server1 和 Server2 具有各自獨立的策略-身分關係。

如先前所述，KES 伺服器會從其憑證計算客戶端身分。這通常會計算為加密 SHA-256 值。但是，在指定身分-策略對應時，將任意身分值關聯到策略是完全有效的。關聯的身分可以是 "_"、"disabled"、"foobar123" 或任何其他值。這對於處理特殊的根身分特別有用。

KES 伺服器具有特殊的 root 身分，您 必須 指定。您可以透過 KES 設定檔 或 --root CLI 選項來指定 root 身分。一般而言，root 的行為就像任何其他身分，但無法關聯到策略。相反的，root 可以執行任意的 API 操作。

root 身分對於初始佈建和管理任務特別有用。

集中管理或自動化部署（例如 Kubernetes）不需要 root 身分，它僅作為一種安全風險。如果攻擊者取得 root 身分的私鑰和憑證，則攻擊者可以執行任意操作。

即使必須始終指定 root 身分，您也可以有效停用它。這可以透過指定一個永遠不會是實際 (SHA-256) 雜湊值的 root 身分值來完成。例如 --root=_（底線）或 --root=disabled。由於 KES 永遠不會將加密身分計算為 _ 或 disabled，因此無法以 root 的身分執行操作。