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

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

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

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

為什么要認(rèn)證

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

概念梳理

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

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

什么是授權(quán)

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

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

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

kubernetes的認(rèn)證

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

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

kubernetes的授權(quán)

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

2.3 kubernetes的AdmissionControl

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

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

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

網(wǎng)站欄目：『高級(jí)篇』docker之kubernetes理解認(rèn)證、授權(quán)（37）
本文網(wǎng)址：http://jinyejixie.com/article0/igogio.html

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

廣告

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