身份認證和權限控制

這次在讀《kubernetes權威指南》時，看到第六章對身份認證和權限控制這部分的內容。自己平時雖然一直都在使用這兩個功能，但理解的最覺得很片段。這裏將原理整體介紹了（自己感覺的），在此做以摘抄。

我們都知道，Kubernetes 集羣中所有的資源訪問和變更都是通過 Kubernetes API Server 的 REST API 來實現的，所以集羣安全的關鍵點就在於如何識別並認證（Authentication）客戶端身份，以及隨後的訪問權限的授權（Authorization）這兩個關鍵的問題，本節對認證管理進行說明。

我們知道，Kubernetes 提供了三種級別的客戶端認證方式。

1. 最嚴格的 HTTPS 證書認證：基於 CA 根證書籤名的雙向數字證書認證方式。
2. HTTP Token 認證：通過一個 Token 來識別合法用戶。
3. HTTP Base 認證：通過 用戶名+密碼的方式認證。

一般的服務程序所使用的用戶身份認證方式也應該在上述三種方式中。

HTTPS 證書認證的原理。

（這是我一直想知道的，但卻總是忘了查）

這裏需要一個 CA 證書，我們知道 CA 是PKI 系統中通信雙方都信任的實體，被稱爲可信第三方（Trusted Third Party，TTP）。CA 所謂可信第三方的重要條件之一就是 CA 的行爲具有非否認性。作爲第三方而不是簡單的上級，就必須能讓信任者有追究自己責任的能力。CA 通過證書證實他人的公鑰信息，證書上有 CA 的簽名。用戶如果因爲信任證書而有了損失，則證書可以所謂有效的證據用於追究 CA 的法律責任。正式因爲 CA 承擔責任的承諾，所以 CA 也被稱爲可信第三方。CA 與用戶是相互獨立的實體，CA 作爲服務提供方，有可能應爲服務質量問題（例如：發佈的公鑰信息有錯誤）給用戶帶來損失。在證書中綁定了公鑰數據和相應私鑰擁有者的身份信息，並帶有 CA 的數字簽名；在證書中也包含了 CA 的名稱，以便依賴方找到 CA 的公鑰，驗證證書上的數字簽名。

這塊是自己理解的：
CA 是個身份信息鑑定機構，用戶（客戶端或者服務器）將自己的身份信息寫成公鑰交給 CA 去鑑定，如果 CA 鑑定身份屬實後會給用頒發一張證書，這張證書裏有：公鑰、私鑰擁有者的身份信息、數字簽名。數字簽名就相當於 CA 往證書的右下角蓋了一個紅戳，用於向其他用戶表明，這張證書上的公鑰信息和私鑰信息是我這個CA 鑑定的，我擔保這些信息是正確的、安全的、可信的，你們（其他用戶）如果因爲相信這張證書而被騙了，我這個 CA 負責賠償損失，並承擔法律責任。

CA 認證涉及諸多概念，比如根證書、自簽名證書、**、私鑰、加密算法及 HTTPS 協議等，本書大致講述 SSL 協議流程，有助於理解 CA 認證和 Kubernetes CA 認證的配置過程。

1. HTTPS 通信雙方的服務器端向 CA 機構申請證書，CA 機構是可信任的第三方機構，它可以是一個公認的權威企業，也可以是企業自身。企業內部系統一般用企業自身的認證系統。CA 機構下發根證書、服務端證書以及私鑰給申請者。
2. HTTPS 通信雙方的客戶端向 CA 機構申請證書，CA 機構下發根證書、客戶端證書以及私鑰給申請者。
3. 客戶端向服務器發起請求，服務端下發服務端證書給客戶端。客戶端接收到證書後，通過私鑰解密證書，並利用好服務器端證書中的公鑰認證證書信息比較證書裏的消息（這塊比較拗口，我的理解是：CA 頒發給服務器的根證書和 服務器下發給客戶端的證書不是同一個東西，根證書是服務端證書的一部分。換句話說就是：服務器在根證書的基礎上又添加了一些服務器的相關信息，構成了服務端證書，最後下發給了客戶端），例如：比較域名和公鑰與服務器剛剛發送的消息是否一致。如果一致，則客戶端認可這個服務器的合法身份。
4. 客戶端發送客戶端證書給服務器端，服務器端在接收到證書後，通過私鑰解密證書，獲取客戶端證書公鑰，並用該公鑰認證（客戶端）證書信息，確認客戶端身份是否合法。
5. 客戶端通過隨機**加密信息，併發送加密後的信息給服務端。在服務端和客戶端商量好加密方案後，客戶端會產生一個隨機的**，客戶端通過協商好的加密方案加密該隨機**，併發送該隨機**到服務器端。服務器端接收到這個**後，雙方通信全部內容都會通過該**加密。（這個應該是對稱加密的過程，也就是說在執行完第4步後，服務器與客戶端都已經確認對方的身份了，第5步開始執行傳輸數據前的對稱加密過程）

上述是雙向認證SSL協議的具體通信過程，這種情況要求服務器和客戶端都要有證書。單向認證SSL協議則不需要客戶端擁有CA證書。在上述的步驟中只需要將服務器驗證客戶端證書的步驟去掉，之後協商對稱密碼方案和對稱通話**時，服務器發送給客戶的密碼沒被加密即可。

HTTP Token 認證原理

HTTP Token 的認證是用一個很長的特殊編碼方式的並且難以被模仿的字符串----Token 來表明用戶身份的一種方式。在通常情況下，Token 是一個很複雜的字符串，比如我們用私鑰簽名一個字符串後的數據就可以被當做一個 Token。此外每一個Token 對應一個用戶名，存儲在 API-server 能訪問的一個文件中。當客戶端發起 API 調用請求時，需要再 HTTP Header 裏放入 Token，這樣一來，API-server 就能識別合法用戶與非法用戶了。（如果是 web服務端程序，Token應該是存放在瀏覽器的 Cookie中吧）。

HTTP Base 認證

我們都知道 HTTP 是無狀態的，瀏覽器和 Web服務器可以之前可以通過 Cookie 來進行身份識別。桌面應用程序（新浪桌面客戶端、命令行程序）一般不會使用 Cookie，那他們與 Web服務器之間是如何進行身份識別呢？這就用到了 HTTP Base 認證，這種認證方式是把「用戶名+冒號+密碼」用 BASE64 算法進行編碼後的字符串放在 request 中的 Header Authentication 域裏發送給服務端，服務端在收到後進行解碼，獲取用戶名及密碼，然後進行身份鑑權。