k8s權限管理

1 總覽

client發起apiserver調用時，apiserver先認證(Authentication)用戶，再給用戶受權(Authorization)，最後執行准入控制(Admission Control)

• 認證：鑑別發起請求的用戶是否合法
• 受權：授予用戶api請求權限，並鑑別用戶訪問的api請求是否合法
• 准入控制：一些額外的檢查機制，用於作最後的攔截

2 認證

認證就是識別用戶身份的過程

2.1 client證書

2.1.1 原理

基於CA根證書籤名的雙向數字證書認證

• client和server向CA機構申請證書
• client->server，server下發服務端證書，client利用證書驗證server是否合法
• client發送客戶端證書給server，server利用證書校驗client是否合法
• client和server利用隨機密鑰加密消息，而後通訊

2.1.2 操做

apiserver啓動的時候經過--client-ca-file=XXXX配置簽發client證書的CA，當client發送證書過來時，apiserver使用CA驗證，若是證書合法，提取Common Name字段做爲用戶名

2.1.3 優勢

1. 安全

2.1.4 缺點

1. 使用稍複雜
2. 沒法撤銷用戶證書

2.2 靜態Token文件

2.2.1 原理

生成一個長串token，並放入header發起http請求，apiserver依據token識別用戶

2.2.2 操做

apiserver啓動經過--token-auth-file=XXXXX加載全部用戶token，client請求的時候Header加上token便可

2.2.3 優勢

1. 簡單

2.2.4 缺點

1. 須要重啓apiserver才能更新，不靈活
2. 不安全

2.3 引導Token

保證token動態生成，可是該方案正在試驗階段，不太成熟

2.4 靜態密碼文件

2.4.1 原理

將[username:password]進行加密存入http request中的Header Authorization域，併發送給apiserver，apiserver依據這個域中的信息識別用戶

2.4.2 操做

apiserver啓動時經過參數--basic-auth-file=XXXX指定用戶信息的文件路徑，client請求的時候Header帶上base64(user:password)便可

若是是經過kubectl，請參考，帶上用戶名密碼，去除證書認證

kubectl --server=https://10.20.46.113:6443 --insecure-skip-tls-verify=true --username=xxx --password=xxx get nodes

2.4.3 優勢

1. 簡單

2.4.4 缺點

1. 須要重啓apiserver才能更新，不靈活
2. 不安全

2.5 Service Account Tokens

主要面向pod內部訪問apiserver的鑑權方式。controller manager和apiserver會利用server端的私鑰爲每一個pod建立一個token，並掛載到/run/secrets/kubernetes.io/serviceaccount/路徑下。pod在訪問apiserver的時候帶上該token就行

備註：當使用pod訪問apiserver的安全端口時，只能採用這種方式

2.6 openId

基於OAuth2協議認證，受各大雲提供商青睞

2.7 Webhook Token

按照規定k8s的接口規範，自定義token認證

2.8 keystone password

openstack提供的認證和受權方案，適合採用openstack體系搭建k8s的團隊，處於試驗階段

2.9 匿名請求

當開啓匿名請求時，全部沒有被拒絕的請求都被認爲是匿名請求，在受權階段，這些請求都被統一處理

3 受權

受權就是授予用戶請求權限，並鑑別用戶的api請求是否合法的過程

目前支持的幾種受權策略：

• AlwaysDeny：拒絕全部請求，用於測試
• AlwaysAllow：容許全部請求，k8s默認策略
• ABAC：基於屬性的訪問控制。表示使用用戶配置的規則對用戶請求進行控制
• RBAC：基於角色的訪問控制
• Webhook：經過調用外部rest服務對用戶受權

主要詳解後三個策略

3.1 ABAC受權模式

啓動ABAC，須要apiserver指定受權策略文件的路徑和名字（--authorization-policy-file=XXXX），文件中的每一行表明一個策略對象

思路：用戶發送請求到apiserver，用戶識別用戶所擁有的權限策略信息，並與authorization-policy-file中的策略一一匹配，若是至少一行匹配成功，該請求就經過了受權

添加新的ABAC策略，須要重啓apiserver

3.2 Webhook受權模式

須要提供一個https接口，並按照指定規規範處理request和響應response

3.3 RBAC受權模式

在k8s中比較推薦的實現方式

優點：

• 對集羣資源和非資源權限都有完整的覆蓋
• 能夠經過kubectl或者api來操做
• 能夠運行時調整，無需重啓apiserver

啓動RBAC，須要apiserver啓動參數加上-authorization-mode=RBAC

RBAC的四個資源對象：

1. Role：一個角色就是一組權限的集合，擁有某個namespace下的權限
2. ClusterRole：集羣角色，擁有整個cluster下的權限
3. RoleBinding：將Role綁定目標（user、group、service account）
4. ClusterRoleBinding：將ClusterRoleBinding綁定目標

一個典型的映射關係

4 准入控制

通過認證和受權後，還須要通過多個准入控制器的審覈，client到apiserver的請求才能成功獲得相應

目前提供的准入控制器有這些（這些插件並非都啓用了）：

• AlwaysAdmint：容許全部請求
• AlwaysPullImages：每次擴容都要從新下載鏡像
• AlwaysDeny：禁止全部請求
• DenyExecOnPrivileged：棄用，攔截全部Privileged Container上執行命令的請求
• DenyEscalatingExec：攔截全部exec和attach到特權pod上的請求
• ImagePolicyWebhook：容許後端的Webhook程序完成准入控制的功能
• ServiceAccount：讓ServiceAccount實現自動化
• SecurityContextDeny：讓pod定義的SecurityContext失效，禁用容器設置的非安全訪問權限
• ResourceQuota：攔截會讓namespace超標的請求
• LimitRanger：限制namespace中全部pod請求的資源數量
• InitialResources：dev階段，爲沒有限制資源的pod設置默認限制
• NamespaceLifecycle：禁止在不存在的namespace中建立資源；刪除namespace會級聯刪除底下的全部pod、service等
• DefaultStorageClass：給未指定StorageClass或PV的PVC匹配默認StorageClass
• DefaultTolerationSeconds：給pod設置默認容忍時間
• PodSecurityPolicy：根據可用的PodSecuirityPolicy和pod的security context來進行安全控制

5 注意

• 經過curl來測試權限是否生效的時候，請確保使用高版本的curl（已知低版本7.19.7）

• 主要參考資料爲【Kubernetes權威指南:從Docker到Kubernetes實踐全接觸(記念版)】。官方文檔略坑，不少東西只介紹了片斷，很難基於它實踐