k8s用戶認證機制的公文地址:field作為用戶id，O field作為用戶組。我們可以使用openssl工具來頒發證書(kubernetes 1.4之後，證書中支持用戶組信息):
上面的操作會生成壹個證書請求，用戶名是jbeda，屬於app1和app2兩個用戶組。
靜態令牌列表文件需要提前放在api服務器上，在API服務器的啟動參數中加入-token-auth-file = some file。令牌文件采用csv格式，至少應包含三個字段(用逗號分隔):令牌、用戶名、用戶uid和壹個可選的組名字段，例如:
註意，如果有多個用戶組，整個用戶組需要用雙引號括起來。
版本1.18已進入穩定版本，支持集群啟動時令牌的動態創建和管理。配置很多，這裏不需要贅述。有興趣的話可以直接參考官方文件。
類似於靜態令牌文件，只使用用戶名和密碼進行認證，使用令牌字段為我們需要的令牌(jwt格式)的es.io/service-account-token,，我們可以用這個令牌直接發起請求。註意，保存在secret中的令牌是用base64編碼的，在實際使用之前需要用base64解碼。可以使用jwt.io網站查看這個令牌。以下是k8s發布的jwt令牌有效負載的壹些字段的示例:
壹種新的基於Oauth2的認證方法比較復雜。有興趣可以參考官方文件，這裏就不介紹了。對Oauth2認證和JWT技術感興趣的可以參考我之前的博文，深入了解春雲安全OAuth2和JWT。(閱讀量4萬多，也是爆款:)
認證完成後，下壹步就是授權。得益於k8s的優秀設計，認證和授權是解耦的，所以只要k8系統識別出用戶身份(用戶名或者uid)，接下來要做的事情也是壹樣的。被授權方的官方文件地址:es.io/docs/reference/access-authn-authz/rbac/.
其實k8s本身也支持很多類型的授權，比如rbac、abac、node、動態接納等等。這裏只介紹最常用的rbac(基於角色的訪問控制)。在實際使用中，api-server開啟authorization-mode = rbac參數，意味著rbac功能啟動。
如果妳熟悉rbac本身，k8s中的rbac功能是非常好理解的。有兩個與rbac相關的api對象。角色定義了壹個角色，並說明了該角色可以操作的功能列表。rolebinding實際上綁定了用戶和角色。
角色的api對象示例:
這個yaml定義了壹個名為pod-reader的角色對象，其作用域為默認名稱空間，可用於獲取、觀察和列出pod。
Kubernetes完整的操作類型列表如下，都很好理解，不壹壹解釋:
值得註意的是，有些資源還有子類型，比如pod的日誌。如果需要查看它們，還需要授權(添加窗格/日誌資源類型)。
RoleBinding資源的作用也很好理解，就是綁定角色和用戶。以下是角色綁定的壹個示例:
在此示例中，名為user is jane的用戶被綁定到pod-reader角色。註意subjects中的kind字段，也就是前面介紹的用戶類型，即User、Group和ServiceAccount。綁定完成後，當使用用戶jane調用k8s api時，可以執行指定的watch、get和list操作。
事實上，這兩種資源的配置方式與Role和RoleBinding完全相同。區別在於ClusterRole和ClusterRoleBinding的作用域是集群範圍的，可以操作節點等集群範圍的資源，而Role和RoleBinding需要在元數據中指定命名空間字段，其他方面沒有區別。
了解了原理之後，現在來實際操作壹下。目標是使用kubectl客戶機工具在給定的k8集群上執行受限的操作。基於上述認證策略的介紹，我們使用客戶端證書對用戶進行認證，即使用K8集群的根證書頒發壹個用戶證書，並使用該證書對用戶進行認證和授權。
制作RSA證書請參考官網文檔:es.io/docs/concepts/cluster-administration/certificates/,在這裏我們使用常用的openssl工具制作證書:
1.創建壹個2048位RSA私鑰。
2.創建壹個證書簽名請求(csr)，其中CN-對應於用戶名O-對應於用戶組，如上面的文章所述。
3.使用群集根證書發布此證書請求(天數為證書到期時間，可根據實際需要進行配置)。
首先找壹個準備好訪問k8集群的linux服務器(或者windows或者mac)作為客戶端，確保客戶端與集群的api-server端口連接(壹般是6443端口，必須是https連接)。出於安全考慮，操作k8最好開通專門的操作系統賬號。將集群主節點中的kubectl二進制文件復制到server /usr/bin目錄，並將三個文件release.csr、release.key和ca.pem復制到服務器上的指定目錄。
在新用戶的主目錄下創建壹個. kube目錄，並在該目錄下創建壹個新的配置文件(或者直接執行kubectl config set-cluster test操作，kubectl會自動創建文件)，編輯文件並填寫以下內容:
完成後，您可以運行kubectl config view來驗證配置是否正確。
使用administrator登錄k8集群並配置權限。這裏以增加集群範圍的運維用戶權限為例:
大家可以看到，我們定義了壹個角色發布，用於應用部署和日常運維。為了滿足日常的運維，給它分配了壹組受限的資源權限。
具體來說，此角色對“部署”、“服務”、“配置映射”和“PVC”資源具有完全操作權限，但對“節點”、“事件”、“窗格”、“窗格/日誌”和“端點”僅具有查看權限，對其他資源沒有權限。
這裏我們定義了壹個ClusterRoleBinding，它綁定了User和ClusterRole，所有的操作都在這裏完成。
登錄客戶端，如果壹切順利，可以通過執行kubectl get pods返回遠程集群默認名稱空間中的pods列表，其他配置的權限也應該可以正常工作。如果該用戶想要訪問受限資源，例如查看機密信息，將會出現以下錯誤消息(403禁止):
驗證成功！
基於上面的描述，我們可以知道，其實在集群中創建壹個服務賬號，復制它的token，在客戶端的kubectl配置文件中進行配置，也可以達到同樣的效果，這裏就不做演示了。
因為服務賬號的token機密信息實際上是存儲在secret對象中的，而secret經常被抱怨存儲的數據是明文(只有base64編碼)，所以這裏又多了壹個關於secret安全性的問題。其實k8s是支持秘密加密存儲的，支持的加密類型也不少。詳情請看我的文章:用加密插件在秘密中加密數據。但實際上我並不推薦使用這種方式，因為加密插件只能對etcd中存儲的數據進行加密，api服務器檢索到的數據仍然是解密的，也就是說通過執行kubectl get secrets或者查看容器的環境變量仍然可以看到明文數據。K8s項目比較推薦的權限管理方式是:
做好以上兩點，對於壹般公司的安全控制就足夠了。畢竟集群管理員的權限只掌握在壹小部分人手裏。對於安全審計要求較高的企業(如金融機構)，審計可能要求敏感數據必須加密，此時可以使用api-server的加密插件。