理解認證授權

1.1 為什麽要認證

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

1.2 概念梳理

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

• 對稱加密/非對稱加密
  這兩個概念屬於密碼學的東西，對於沒接觸過的同學不太容易理解。可以參考知乎大神的生動講解：《如何用通俗易懂的話來解釋非對稱加密》

• SSL/TLS
  了解了對稱加密和非對稱加密後，我們就可以了解一下SSL/TLS了。同樣，已經有大神總結了非常好的入門文章：《SSL/TLS協議運行機制的概述》

1.3 什麽是授權

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

2. kubernetes的認證授權

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

2.1 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 的文件系統中。

2.2 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，則這個請求被拒絕。

k8s認證授權詳解