眾所周知，任意壹個系統的安全機制的核心都是基於 認證與授權 （Authentication and Authorization）,即首先通過某種方式確認“妳”的身份，再根據壹定的授權策略確定“妳”在我的系統裏面能做什麽操作。對於K8S來說，就是體現為客戶端對於 kube-apiserver 的api接口操作的鑒權（客戶端可以是集群內的工作負載pod，任意服務器上的kubectl程序，或是計算節點上的kubelet組件等等）。Kubernets項目作為壹個成熟的開源雲計算基礎設施項目，讓我們來看看他們是如何解決認證與授權這兩個核心問題的：
k8s的用戶認證機制的官方文檔地址： 字段作為用戶id，O字段作為用戶組。我們可以使用openssl工具來進行證書的簽發（kubernetes 1.4之後支持了證書中攜帶用戶組信息）：
上述操作會生成壹個證書請求，username為 jbeda ，並同時屬於兩個用戶組 app1 和 app2 。
靜態token列表文件，需要預先在 API Server 服務器上放置該文件，並且在api server的啟動參數中加上 --token-auth-file=SOMEFILE ,token文件為csv格式，應至少包含token, user name, user uid這三個字段(逗號分隔)以及壹個可選的group names字段，例如：
註意如果用戶組有多個的話，整個用戶組需要用雙引號括起來。
1.18版本進入穩定版的新特性，支持可以在集群啟動時動態的創建和管理token，配置比較多，這裏不多贅述，有興趣直接參考官方文檔
跟靜態 Token 文件類似，只是使用了用戶名密碼的形式進行認證，使用的是es.io/service-account-token ，其中token字段即為我們需要的令牌（jwt格式），拿著這個令牌就可以直接發起請求了。 註意在secret中保存的token是經過base64編碼的，實際使用時還需要先進行base64解碼操作，可以使用jwt.io網站來查看這個令牌，以下是k8s簽發的壹個jwt令牌payload部分字段的示例：
新出來的壹種認證方式，基於Oauth2，比較復雜，有興趣可以參考官方文檔，這裏不介紹了。對於Oauth2認證以及JWT技術比較感興趣的，可以參考我之前的博文 深入理解Spring Cloud Security OAuth2及JWT 。（閱讀量4萬多了，也算爆款了:）
搞定了認證，接下來就是授權了。得益於k8s優良的設計，認證和授權是解耦的，所以只要k8系統識別出了用戶身份（username或者uid），接下來要做的事情就是壹樣的了。關於授權部分的官方文檔地址： es.io/docs/reference/access-authn-authz/rbac/
事實上k8s本身也支持多種授權類型，比如rbac，abac，node，dynamic admission 等等。這裏只介紹下最常用的rbac（基於角色的訪問控制），實際使用中，api-server開啟 --authorization-mode=RBAC 參數，即啟動了rbac功能。
如果妳對於rbac本身已經比較了解，那麽其實k8s裏面的rbac功能就非常容易理解了。涉及rbac的有兩個api對象，role定義了壹個角色，申明了此角色可以操作的功能列表，rolebinding其實就是把用戶和角色做了壹個綁定。
role的api對象示例：
這個yaml定義了壹個Role對象，名稱為 pod-reader ， 作用域為 default 這個namespace，可以對 pods 這個對象進行 get 、 watch 、 list 操作。
kubernetes完整的操作類型列表如下，都很好理解，不壹壹說明了：
值得註意的是，有些資源還有子類型，比如pod的logs，如果需要查看，也是需要授權的(添加 pods/log 資源類型)
RoleBinding資源的作用也非常容易理解， 就是綁定Role和用戶。下面是壹個RoleBinding的示例：
這個例子裏把壹個類型為User，name叫做jane的用戶，和pod-reader的Role做了綁定。註意subjects裏面的 kind 字段，即用戶類型，前面介紹過了，分別是 User 、 Group 和 ServiceAccount 。綁定完成之後，當使用 jane 這個用戶身份對k8s的api進行調用，就可以進行指定的 watch 、 get 、 list 操作了。
這兩資源其實和Role、RoleBinding的配置方式是完全壹樣的，區別在於ClusterRole和ClusterRoleBinding的作用域是集群範圍的，並且可以操作 node 這樣的集群範圍資源，而Role、RoleBinding在metadata中需要指定namespace字段，其他方面沒有區別。
弄清原理之後，現在讓我們來實際操作壹下，目標是使用kubectl客戶端工具對於給定的k8集群進行受限操作。基於上述的認證策略的介紹，我們使用 客戶端證書 方式來進行用戶認證，即使用K8集群的根證書來簽發壹個用戶證書，使用該證書來進行用戶認證及授權操作。
關於RSA證書的制作，可以參考官網文檔： es.io/docs/concepts/cluster-administration/certificates/ ，這裏我們使用常用的openssl工具來制作證書：
1、創建壹個2048位長度的RSA格式私鑰
2、創建證書簽名請求(csr)，CN-對應Username O-對應用戶組，上面的文章中已經介紹過
3、使用集群根證書簽發這個證書請求(days是證書到期時間，可根據實際需要配置)
首先先找到壹臺準備作為客戶端訪問k8集群的linux服務器（或者windows、mac都可以），確保客戶端與集群的api-server端口網絡聯通（壹般為6443端口，註意必須是https連接），出於安全考慮，最好開壹個操作k8的專用的操作系統賬號。把集群master節點中的kubectl二進制文件拷貝至此服務器/usr/bin目錄內，同時拷貝release.csr、release.key、ca.pem這三個文件至服務器上的指定目錄。
在新建用戶的home目錄下創建.kube目錄，在此目錄下新建config文件（或者直接執行kubectl config set-cluster test操作，kubectl會自動創建該文件），編輯該文件填寫如下內容：
完成之後可以執行 kubectl config view 來驗證壹下配置是否正確。
使用管理員登陸k8集群，進行權限配置，這裏以添加集群範圍的運維用戶權限為例：
可以看到，我們定義了壹個角色 release ，用於應用的部署及日常運維操作。為了滿足日常運維，給其分配了壹組受限的資源權限。
具體來說，該角色對"deployments","services","configmap","pvc"資源有全部的操作權限，對於"nodes","events","pods","pods/log","endpoints"只有查看權限，對於其他資源沒有任何權限。
這裏我們定義了壹個ClusterRoleBinding，把User和ClusterRole進行了綁定，到這裏全部操作就完成了。
登陸客戶端，壹切順利的話，執行 kubectl get pods 就可以返回遠程集群的default命名空間下的pods列表了，其他配置的權限應該也可以正常操作。而如果這個用戶想訪問受限資源，比如想查看secrets信息，則會出現如下的報錯信息(403 Forbidden)：
驗證成功！
基於上述的描述，可以知道，其實在集群裏面創建壹個service account，把它的token拷貝出來，配置在客戶端的kubectl配置文件中，可以達到同樣的效果，這裏就不再演示了。
因為service account的token機密信息實際上都是存放於secret對象中，而secret經常被人吐槽的是存放的數據是明文（只是做了base64編碼），所以這裏多說壹句secret的安全性問題。其實k8s是支持secret加密存放的，支持的加密類型還挺多，具體可以看我這篇文章： 使用加密插件加密secrets中的數據 。但其實我並不建議使用這種方式，原因是使用加密插件只能加密存放在etcd裏面的數據，而使用api server調取出的數據仍然是解密過後的，這意味著妳執行 kubectl get secrets 或者是進入容器的環境變量查看，仍然可以看到明文數據。k8s項目更推薦的權限管理方式是：
做好上面兩點，對於壹般公司的安全管控來講已經足夠，畢竟集群管理員的權限只是掌握在很小壹部分人的手中。而對於安全審計要求更高的企業（比如金融機構），審計可能會有要求敏感數據必須加密存放，此時可使用api-server的加密插件。