『高級篇』docker之kubernetes理解認證、授權（37）

原創(chuàng)文章，歡迎轉載。轉載請注明：轉載自IT人故事會，謝謝！
原文鏈接地址：『高級篇』docker之kubernetes理解認證、授權（37）

創(chuàng)新互聯(lián)提供高防物理服務器租用、云服務器、香港服務器、服務器托管機柜等

從本節(jié)開始完整的kubernetes集群的部署，也就是在前面基礎集群的基礎上增加了認證和授權，業(yè)內對kubernetes的評價的學習曲線陡，不容易入門，很大的原因就是環(huán)境的安裝和部署，環(huán)境的安裝和部署的最終原因其中的一半就歸功于它的認證和授權。

理解認證授權

為什么要認證

想理解認證，我們得從認證解決什么問題、防止什么問題的發(fā)生入手。
防止什么問題呢？是防止有人***你的集群，root你的機器后讓我們集群依然安全嗎？不是吧，root都到手了，那就為所欲為，防不勝防了。
其實網絡安全本身就是為了解決在某些假設成立的條件下如何防范的問題。比如一個非常重要的假設就是兩個節(jié)點或者ip之間的通訊網絡是不可信任的，可能會被第三方竊取，也可能會被第三方篡改。就像我們上學時候給心儀的女孩傳紙條，傳送的過程可能會被別的同學偷看，甚至內容可能會從我喜歡你修改成我不喜歡你了。當然這種假設不是隨便想出來的，而是從網絡技術現(xiàn)狀和實際發(fā)生的問題中發(fā)現(xiàn)、總結出來的。kubernetes的認證也是從這個問題出發(fā)來實現(xiàn)的。

概念梳理

為了解決上面說的問題，kubernetes并不需要自己想辦法，畢竟是網絡安全層面的問題，是每個服務都會遇到的問題，業(yè)內也有成熟的方案來解決。這里我們一起了解一下業(yè)內方案和相關的概念。

• 對稱加密/非對稱加密
  這兩個概念屬于密碼學的東西，對于沒接觸過的老鐵不太容易理解。
  1. 對稱加密會對應一系列的加密算法，key把數據加密，必須用同樣的key同樣的算法可以把明文解出來，速度比較快，但是大家都是用一份明文秘鑰來進行的，安全性不好，如果一個人key泄露，就很危險。
  2. 非對稱加密，特點我用一個key把數據加密后，只有用另外一個key才能把他解密，這種算法就是非對稱加密算法，特征比較安全，并不需要太多的秘鑰，安全性大大的提高。
• SSL/TLS
  了解了對稱加密和非對稱加密后，我們就可以了解一下SSL/TLS了。
  1. SSL和TLS可以認為一個東西的老版本和新版本
  2. 它的機制是建立在對稱加密和非對稱加密的基礎之上，做的一層通信協(xié)議，建立在傳輸層之上應用層之下的中間層協(xié)議，用來保證傳輸的安全性和可靠性。
  3. 先建立非對稱加密的方法互相通信，大家達成一個一致，使用隨機生成的秘鑰進行對稱加密的傳輸，對稱加密是不安全，秘鑰是不安全的，隨機生成生成的秘鑰，這個秘鑰還不想他人知道，這個秘鑰就通過非對稱加密的方式通信，進行達成一致，老鐵咱們使用某一個字符串作為秘鑰，這個會話做成秘鑰來進行對稱加密進行通信。

什么是授權

授權的概念就簡單多了，就是什么人具有什么樣的權限，一般通過角色作為紐帶把他們組合在一起。也就是一個角色一邊擁有多種權限，一邊擁有多個人。這樣就把人和權限建立了一個關系。

kubernetes的認證授權

Kubernetes集群的所有操作基本上都是通過kube-apiserver這個組件進行的，它提供HTTP RESTful形式的API供集群內外客戶端調用。需要注意的是：認證授權過程只存在HTTPS形式的API中。也就是說，如果客戶端使用HTTP連接到kube-apiserver，那么是不會進行認證授權的。所以說，可以這么設置，在集群內部組件間通信使用HTTP，集群外部就使用HTTPS，這樣既增加了安全性，也不至于太復雜。
對APIServer的訪問要經過的三個步驟，前面兩個是認證和授權，第三個是 Admission Control，它也能在一定程度上提高安全性，不過更多是資源管理方面的作用。

kubernetes的認證

kubernetes提供了多種認證方式，比如客戶端證書、靜態(tài)token、靜態(tài)密碼文件、ServiceAccountTokens等等。你可以同時使用一種或多種認證方式。只要通過任何一個都被認作是認證通過。下面我們就認識幾個常見的認證方式。

• 客戶端證書認證
  客戶端證書認證叫作TLS雙向認證，也就是服務器客戶端互相驗證證書的正確性，在都正確的情況下協(xié)調通信加密方案。
  為了使用這個方案，api-server需要用--client-ca-file選項來開啟。
• 引導Token
  當我們有非常多的node節(jié)點時，手動為每個node節(jié)點配置TLS認證比較麻煩，這時就可以用到引導token的認證方式，前提是需要在api-server開啟 experimental-bootstrap-token-auth 特性，客戶端的token信息與預先定義的token匹配認證通過后，自動為node頒發(fā)證書。當然引導token是一種機制，可以用到各種場景中。
• Service Account Tokens 認證
  有些情況下，我們希望在pod內部訪問api-server，獲取集群的信息，甚至對集群進行改動。針對這種情況，kubernetes提供了一種特殊的認證方式：Service Account。 Service Account 和 pod、service、deployment 一樣是 kubernetes 集群中的一種資源，用戶也可以創(chuàng)建自己的 Service Account。
  ServiceAccount 主要包含了三個內容：namespace、Token 和 CA。namespace 指定了 pod 所在的 namespace，CA 用于驗證 apiserver 的證書，token 用作身份驗證。它們都通過 mount 的方式保存在 pod 的文件系統(tǒng)中。

kubernetes的授權

在Kubernetes1.6版本中新增角色訪問控制機制（Role-Based Access，RBAC）讓集群管理員可以針對特定使用者或服務賬號的角色，進行更精確的資源訪問控制。在RBAC中，權限與角色相關聯(lián)，用戶通過成為適當角色的成員而得到這些角色的權限。這就極大地簡化了權限的管理。在一個組織中，角色是為了完成各種工作而創(chuàng)造，用戶則依據它的責任和資格來被指派相應的角色，用戶可以很容易地從一個角色被指派到另一個角色。
目前 Kubernetes 中有一系列的鑒權機制，因為Kubernetes社區(qū)的投入和偏好，相對于其它鑒權機制而言，RBAC是更好的選擇。具體RBAC是如何體現(xiàn)在kubernetes系統(tǒng)中的我們會在后面的部署中逐步的深入了解。

2.3 kubernetes的AdmissionControl

AdmissionControl - 準入控制本質上為一段準入代碼，在對kubernetes api的請求過程中，順序為：先經過認證 & 授權，然后執(zhí)行準入操作，最后對目標對象進行操作。這個準入代碼在api-server中，而且必須被編譯到二進制文件中才能被執(zhí)行。
在對集群進行請求時，每個準入控制代碼都按照一定順序執(zhí)行。如果有一個準入控制拒絕了此次請求，那么整個請求的結果將會立即返回，并提示用戶相應的error信息。
常用組件（控制代碼）如下：

• AlwaysAdmit：允許所有請求
• AlwaysDeny：禁止所有請求，多用于測試環(huán)境
• ServiceAccount：它將serviceAccounts實現(xiàn)了自動化，它會輔助serviceAccount做一些事情，比如如果pod沒有serviceAccount屬性，它會自動添加一個default，并確保pod的serviceAccount始終存在
• LimitRanger：他會觀察所有的請求，確保沒有違反已經定義好的約束條件，這些條件定義在namespace中LimitRange對象中。如果在kubernetes中使用LimitRange對象，則必須使用這個插件。
• NamespaceExists：它會觀察所有的請求，如果請求嘗試創(chuàng)建一個不存在的namespace，則這個請求被拒絕。

PS：這次想說說理論，也理解下，下次直接上手搭建。

網站欄目：『高級篇』docker之kubernetes理解認證、授權（37）
本文網址：http://bm7419.com/article0/igogio.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站排名、外貿建站、商城網站、電子商務、標簽優(yōu)化、定制開發(fā)

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)