k8s認證與受權

認證用於身份鑑別，而受權則實現權限分派。k8s以插件化的方式實現了這兩種功能，且分別存在多種可用的插件。另外，它還支持准入控制機制，用於補充受權機制以實現更精細的訪問控制功能。

1、訪問控制概述

apiserver做爲k8s集羣系統的網關，是訪問及管理資源對象的惟一入口，餘下全部須要訪問集羣資源的組件，包括kube-controller-manager、kube-scheduler、kubelet和kube-proxy等集羣基礎組件、CoreDNS等集羣的附加組件以及此前使用的kubectl命令等都要經由此網關進行集羣訪問和管理。這些客戶端均要經由apiserver訪問或改變集羣狀態並完成數據存儲，並由它對每一次的訪問請求進行合法性檢驗，包括用戶身份鑑別、操做權限驗證以及操做是否符合全局規範的約束等。全部檢查均正常且對象配置信息合法性檢驗無誤後才能訪問或存入數據於後端存儲系統etcd中。

客戶端認證操做由apiserver配置的一到多個認證插件完成。收到請求後，apiserver依次調用爲其配置的認證插件來認證客戶端身份，直到其中一個插件能夠識別出請求者的身份爲止。受權操做由一到多受權插件進行，它負責肯定那些經過認證的用戶是否有權限執行其發出的資源操做請求，如建立、刪除或修改指定的對象等。隨後，經過受權檢測的用戶所請求的修改相關的操做還要經由一到多個准入控制插件的遍歷檢測。

一、用戶帳戶與用戶組

k8s並不會存儲由認證插件從客戶端請求中提取出的用戶及所屬組的信息，他們僅僅用於檢測用戶是否有權限執行其所請求的操做。客戶端訪問api服務的途徑一般有三種：kubectl、客戶端庫或者直接使用rest接口進行請求，而能夠執行此類請求的主體也被k8s分爲兩類：現實中的人和pod對象，它們的身份分別對應於常規用戶和服務帳號。

useraccount（用戶帳號）：通常是指由獨立於k8s以外的其餘服務管理的用戶帳號，例如由管理員分發的密鑰、keystore一類的用戶存儲、甚至是包含用戶名和密碼列表的文件等。k8s中不存在表示此類用戶帳號的對象，所以不能被直接添加進k8s系統中。

serviceaccount（服務帳號）：是指由k8sapi管理的帳號，用於爲pod之中的服務進程在訪問k8sapi時提供身份標識。serviceaccount一般要綁定與特定的名稱空間，它們由apiserver建立，或者經過api調用手動建立，附帶着一組存儲爲secret的用於訪問apiserver的憑據。

useraccount一般用於複雜的業務邏輯管控，它做用於系統全局，故其名稱必須全局惟一。相比較來講，serviceaccount隸屬於名稱空間，僅用於實現某些特定的操做任務，所以要輕量得多。這兩類帳號均可以隸屬於一個或多個用戶組。用戶組只是用戶帳號的邏輯集合，它自己並無操做權限，但附加於組上的權限可由其內部的全部用戶繼承，以實現高效的受權管理機制。

system: unauthenticated:  未能經過任何一個受權插件檢驗的帳號，即未經過認證測試的用戶所屬的組。

system:authenticated: 認證成功後的用戶自動加入的一個組，用於快捷引用全部正常經過認證的用戶帳號。

system:serviceaccounts：當前系統上的全部service account對象。

system:serviceaccounts:<namespace>:特定名稱空間內全部的serviceaccount對象。

api請求要麼與普通用戶或服務帳戶進行綁定，要麼被視爲匿名請求。這意味着集羣內部或外部的每一個進程，包括由人類用戶使用的kubectl，到節點上的kubelet，再到控制平面的成員組件，必須在向api服務器發出請求時進行身份驗證，不然即被視爲匿名用戶。

二、認證、受權與准入控制基礎

api server處理請求的過程當中，認證插件負責鑑定用戶身份，受權插件用於操做權限許可鑑別，而准入控制則用於在資源對象的建立、刪除、更新或鏈接操做時實現更精細的許可檢查。

kubernetes使用身份驗證插件對api請求進行身份驗證，支持的認證方式包括客戶端證書、承載令牌、身份驗證代理或http basic認證等。api server接收到訪問請求時，它將調用認證插件嘗試將如下屬性與訪問請求相關聯。

Username: 用戶名，如kubernetes-admin等。

UID：用戶的數字標籤符，用於確保用戶身份的惟一性。

Groups：用戶所屬組，用於權限指派和繼承

Extra：鍵值數據類型的字符串，用於提供認證時須要用到的額外信息。

api server支持同時啓用多種認證機制，但至少應該分別爲service account和user account各自啓用一個認證插件。同時啓用多種認證機制時，認證過程會以串行的方式進行，直到一種認證機制成功完成即結束。若認證失敗，則服務器會響應401狀態碼，反之，請求者就會被識別爲某個具體的用戶，而且隨後的操做都將以此用戶身份來進行。