『高階篇』docker之kubernetes理解認證、授權（37）
從本節開始完整的kubernetes叢集的部署，也就是在前面基礎叢集的基礎上增加了認證和授權，業內對kubernetes的評價的學習曲線陡，不容易入門，很大的原因就是環境的安裝和部署，環境的安裝和部署的最終原因其中的一半就歸功於它的認證和授權。
理解認證授權
為什麼要認證
想理解認證，我們得從認證解決什麼問題、防止什麼問題的發生入手。
防止什麼問題呢？是防止有人入侵你的叢集，root你的機器後讓我們叢集依然安全嗎？不是吧，root都到手了，那就為所欲為，防不勝防了。
其實網路安全本身就是為了解決在某些假設成立的條件下如何防範的問題。比如一個非常重要的假設就是兩個節點或者ip之間的通訊網路是不可信任的，可能會被第三方竊取，也可能會被第三方篡改。就像我們上學時候給心儀的女孩傳紙條，傳送的過程可能會被別的同學偷看，甚至內容可能會從我喜歡你修改成我不喜歡你了。當然這種假設不是隨便想出來的，而是從網路技術現狀和實際發生的問題中發現、總結出來的。kubernetes的認證也是從這個問題出發來實現的。
概念梳理
為了解決上面說的問題，kubernetes並不需要自己想辦法，畢竟是網路安全層面的問題，是每個服務都會遇到的問題，業內也有成熟的方案來解決。這裡我們一起了解一下業內方案和相關的概念。
– 對稱加密/非對稱加密
這兩個概念屬於密碼學的東西，對於沒接觸過的老鐵不太容易理解。
1. 對稱加密會對應一系列的加密演算法，key把資料加密，必須用同樣的key同樣的演算法可以把明文解出來，速度比較快，但是大家都是用一份明文祕鑰來進行的，安全性不好，如果一個人key洩露，就很危險。
2. 非對稱加密，特點我用一個key把資料加密後，只有用另外一個key才能把他解密，這種演算法就是非對稱加密演算法，特徵比較安全，並不需要太多的祕鑰，安全性大大的提高。
– SSL/TLS
瞭解了對稱加密和非對稱加密後，我們就可以瞭解一下SSL/TLS了。
1. SSL和TLS可以認為一個東西的老版本和新版本
2. 它的機制是建立在對稱加密和非對稱加密的基礎之上，做的一層通訊協議，建立在傳輸層之上應用層之下的中間層協議，用來保證傳輸的安全性和可靠性。
3. 先建立非對稱加密的方法互相通訊，大家達成一個一致，使用隨機生成的祕鑰進行對稱加密的傳輸，對稱加密是不安全，祕鑰是不安全的，隨機生成生成的祕鑰，這個祕鑰還不想他人知道，這個祕鑰就通過非對稱加密的方式通訊，進行達成一致，老鐵咱們使用某一個字串作為祕鑰，這個會話做成祕鑰來進行對稱加密進行通訊。
什麼是授權
授權的概念就簡單多了，就是什麼人具有什麼樣的許可權，一般通過角色作為紐帶把他們組合在一起。也就是一個角色一邊擁有多種許可權，一邊擁有多個人。這樣就把人和許可權建立了一個關係。
kubernetes的認證授權
Kubernetes叢集的所有操作基本上都是通過kube-apiserver這個元件進行的，它提供HTTP RESTful形式的API供叢集內外客戶端呼叫。需要注意的是：認證授權過程只存在HTTPS形式的API中。也就是說，如果客戶端使用HTTP連線到kube-apiserver，那麼是不會進行認證授權的。所以說，可以這麼設定，在叢集內部元件間通訊使用HTTP，叢集外部就使用HTTPS，這樣既增加了安全性，也不至於太複雜。
對APIServer的訪問要經過的三個步驟，前面兩個是認證和授權，第三個是 Admission Control，它也能在一定程度上提高安全性，不過更多是資源管理方面的作用。
kubernetes的認證
kubernetes提供了多種認證方式，比如客戶端證書、靜態token、靜態密碼檔案、ServiceAccountTokens等等。你可以同時使用一種或多種認證方式。只要通過任何一個都被認作是認證通過。下面我們就認識幾個常見的認證方式。
– 客戶端證書認證
客戶端證書認證叫作TLS雙向認證，也就是伺服器客戶端互相驗證證書的正確性，在都正確的情況下協調通訊加密方案。
為了使用這個方案，api-server需要用–client-ca-file選項來開啟。
– 引導Token
當我們有非常多的node節點時，手動為每個node節點配置TLS認證比較麻煩，這時就可以用到引導token的認證方式，前提是需要在api-server開啟 experimental-bootstrap-token-auth 特性，客戶端的token資訊與預先定義的token匹配認證通過後，自動為node頒發證書。當然引導token是一種機制，可以用到各種場景中。
– Service Account Tokens 認證
有些情況下，我們希望在pod內部訪問api-server，獲取叢集的資訊，甚至對叢集進行改動。針對這種情況，kubernetes提供了一種特殊的認證方式：Service Account。 Service Account 和 pod、service、deployment 一樣是 kubernetes 叢集中的一種資源，使用者也可以建立自己的 Service Account。
ServiceAccount 主要包含了三個內容：namespace、Token 和 CA。namespace 指定了 pod 所在的 namespace，CA 用於驗證 apiserver 的證書，token 用作身份驗證。它們都通過 mount 的方式儲存在 pod 的檔案系統中。
kubernetes的授權
在Kubernetes1.6版本中新增角色訪問控制機制（Role-Based Access，RBAC）讓叢集管理員可以針對特定使用者或服務賬號的角色，進行更精確的資源訪問控制。在RBAC中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。在一個組織中，角色是為了完成各種工作而創造，使用者則依據它的責任和資格來被指派相應的角色，使用者可以很容易地從一個角色被指派到另一個角色。
目前 Kubernetes 中有一系列的鑑權機制，因為Kubernetes社群的投入和偏好，相對於其它鑑權機制而言，RBAC是更好的選擇。具體RBAC是如何體現在kubernetes系統中的我們會在後面的部署中逐步的深入瞭解。
2.3 kubernetes的AdmissionControl
AdmissionControl – 准入控制本質上為一段准入程式碼，在對kubernetes api的請求過程中，順序為：先經過認證 & 授權，然後執行准入操作，最後對目標物件進行操作。這個准入程式碼在api-server中，而且必須被編譯到二進位制檔案中才能被執行。
在對叢集進行請求時，每個准入控制程式碼都按照一定順序執行。如果有一個准入控制拒絕了此次請求，那麼整個請求的結果將會立即返回，並提示使用者相應的error資訊。
常用元件（控制程式碼）如下：
– AlwaysAdmit：允許所有請求
– AlwaysDeny：禁止所有請求，多用於測試環境
– ServiceAccount：它將serviceAccounts實現了自動化，它會輔助serviceAccount做一些事情，比如如果pod沒有serviceAccount屬性，它會自動新增一個default，並確保pod的serviceAccount始終存在
– LimitRanger：他會觀察所有的請求，確保沒有違反已經定義好的約束條件，這些條件定義在namespace中LimitRange物件中。如果在kubernetes中使用LimitRange物件，則必須使用這個外掛。
– NamespaceExists：它會觀察所有的請求，如果請求嘗試建立一個不存在的namespace，則這個請求被拒絕。
PS：這次想說說理論，也理解下，下次直接上手搭建。
已是最新文章