目錄
- 身份認證策略
- API Server啟用的身份認證機制
- kubelet啟用的身份認證機制
- X.509數(shù)字證書認證
- 靜態(tài)令牌文件
- Service Account令牌
- OpenID Connect(OIDC)令牌
- Webhook令牌認證
- 身份認證代理
- 靜態(tài)令牌認證配置案例
- 靜態(tài)令牌認證的基礎(chǔ)配置
- 配置示例
- X509 數(shù)字證書認證
- 所有的證書
- X509數(shù)字證書認證測試
身份認證策略
- X.509客戶端證書認證
- 持有者令牌(bearer token)
- 靜態(tài)令牌文件(Static Token File)
- Bootstrap令牌
- Service Account令牌
- OIDC(OpenID Connect)令牌
- Webhook令牌
- 身份認證代理(Authenticating Proxy)
- 匿名請求
API Server啟用的身份認證機制
基于認證插件支持多種認證方式,而相應(yīng)認證插件的啟用需要經(jīng) 由kube-apiserver上的專用選項完成 kubeadm v1.26 部署的集群默認啟用的認證機制如右圖紅框中的選 項,它們依次是
- X509客戶端證書認證
- Bootstrap令牌認證
- 身份認證代理
- Service Account認證
注意:API Server并不保證各認證插件的生效次序與定義的次序相同
kubelet啟用的身份認證機制
kubelet的REST API端點默認通過TCP協(xié)議的10250端口提供,支持管理操作
需要對客戶端身份進行認證
- 啟用的身份認證
- webhook
- x509客戶端證書認證
- 注意:建議顯式禁用匿名用戶
- API Server是該API端點的客戶端,因此,kubelet需要在驗證客戶端身份時信任給API Server 頒發(fā)數(shù)字證書的CA
X.509數(shù)字證書認證
在雙向TLS通信中,客戶端持有數(shù)字證書,而API Server信任客戶端證書的頒發(fā)者
- 信任的CA,需要在kube-apiserver程序啟動時,通過–client-ca-file選項傳遞
- 認證通過后,客戶端數(shù)字證書中的CN(Common Name)即被識別為用戶名,而O(Organization)被識別為組名
- kubeadm部署的Kubernetes集群,默認使用 /etc/kubernetes/pki/ca.crt 進行客戶端認證
- /etc/kubernetes/pki/ca.crt是kubeadm為Kubernetes各組件間頒發(fā)數(shù)字證書的CA
靜態(tài)令牌文件
令牌信息保存于文本文件中 由kube-apiserver在啟動時通過–token-auth-file選項加載 加載完成后的文件變動,僅能通過重啟程序進行重載,因此,相關(guān)的令牌會長期有效 客戶端在HTTP請求中,通過“Authorization Bearer TOKEN”標頭附帶令牌令牌以完成認證
Service Account令牌
- 該認證方式將由kube-apiserver程序內(nèi)置直接啟用
- 它借助于經(jīng)過簽名的Bearer Token來驗證請求
- 簽名時使用的密鑰可以由–service-account-key-file選項指定,也可以默認使用API Server的tls私鑰
- 用于將Pod認證到API Server之上,以支持集群內(nèi)的進程與API Server通信
- Kubernetes可使用ServiceAccount準入控制器自動為Pod關(guān)聯(lián)ServiceAccount
OpenID Connect(OIDC)令牌
OAuth3認證機制,通常由底層的IaaS服務(wù)所提供
Webhook令牌認證
- 是一種用于驗證Bearer Token的回調(diào)機制
- 能夠擴展支持外部的認證服務(wù),例如LDAP等
身份認證代理
- 由kube-apiserver從請求報文的特定HTTP標頭中識別用戶身份,相應(yīng)的標頭名稱可由特定的選項配置指定
- kube-apiserver應(yīng)該基于專用的CA來驗證代理服務(wù)器身份
靜態(tài)令牌認證配置案例
靜態(tài)令牌認證的基礎(chǔ)配置
- 令牌信息保存于文本文件中
- 文件格式為CSV,每行定義一個用戶,由“令牌、用戶名、用戶ID和所屬的用戶組”四個字段組成,用戶組為可選字段
- 格式:token,user,uid,"group1,group2,group3"
- 由kube-apiserver在啟動時通過–token-auth-file選項加載
- 加載完成后的文件變動,僅能通過重啟程序進行重載,因此,相關(guān)的令牌會長期有效
- 客戶端在HTTP請求中,通過“Authorization Bearer TOKEN”標頭附帶令牌令牌以完成認證
配置示例
- ① 生成token,命令:echo "(opensslrand−hex3).(openssl rand -hex 3).(opensslrand−hex3).(openssl rand -hex 8)"
- ② 生成static token文件
- ③ 配置kube-apiserver加載該靜態(tài)令牌文件以啟用相應(yīng)的認證功能
- ④ 測試,命令:curl -k -H "Authorization: Bearer TOKEN" -k https://API_SERVER:6443/api/v1/namespaces/default/pods/
X509 數(shù)字證書認證
X509客戶端認證依賴于PKI證書體系,kubeadm部署Kubernetes集群時會自動生成所需要的證書,它們位于/etc/kubernetes/pki目錄下
依賴到的PKI體系
另外,對Service Account的token進行簽名還需要用到一個可選的密鑰對兒
所有的證書
- 各kubelet的證書可在Bootstrap過程中自動生成證書簽署請求,而后由Kubernetes CA予以簽署
- 各kube-proxy、kube-scheduler和kube-controller-manager也都有相應(yīng)的數(shù)字證書以完成向API Server的身份認證
X509數(shù)字證書認證測試
創(chuàng)建客戶端私鑰和證書簽署請求,為了便于說明問題,以下操作在master節(jié)點上以/etc/kubernetes/為工作目錄
1 生成私鑰: (umask 077; openssl genrsa -out ./pki/mason.key 4096)
2 創(chuàng)建證書簽署請求: openssl req -new -key ./pki/mason.key -out ./pki/mason.csr -subj "/CN=mason/O=developers"
3 由Kubernetes CA簽署證書: openssl x509 -req -days 365 -CA ./pki/ca.crt -CAkey ./pki/ca.key -CAcreateserial -in ./pki/mason.csr -out ./pki/mason.crt
4 將pki目錄下的mason.crt、mason.key和ca.crt復(fù)制到某部署了kubectl的主機上,即可進行測試
- 這里以k8s-node01為示例;只需要復(fù)制mason.crt和mason.key即可,因為集群工作節(jié)點上已經(jīng)有cr.crt文件
- 命令:scp -rp ./pki/{mason.crt,mason.key} k8s-node01:/etc/kubernetes/pki
以上就是k8s實現(xiàn)身份認證策略及過程解析的詳細內(nèi)容,更多關(guān)于k8s 身份認證的資料請關(guān)注其它相關(guān)文章!