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

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

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

理解認(rèn)證授權(quán)

為什么要認(rèn)證

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

概念梳理

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

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

什么是授權(quán)

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

kubernetes的認(rèn)證授權(quán)

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

kubernetes的認(rèn)證

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

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

kubernetes的授權(quán)

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

2.3 kubernetes的AdmissionControl

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

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

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