k8s授權(quán)管理介紹與實戰(zhàn)(RBAC)
授權(quán)管理
授權(quán)發(fā)生在認(rèn)證成功之后，通過認(rèn)證就可以知道請求用戶是誰， 然后Kubernetes會根據(jù)事先定義的授權(quán)策略來決定用戶是否有權(quán)限訪問，這個過程就稱為授權(quán)。
每個發(fā)送到ApiServer的請求都帶上了用戶和資源的信息：比如發(fā)送請求的用戶、請求的路徑、請求的動作等，授權(quán)就是根據(jù)這些信息和授權(quán)策略進(jìn)行比較，如果符合策略，則認(rèn)為授權(quán)通過，否則會返回錯誤。
API Server目前支持以下幾種授權(quán)策略：
- AlwaysDeny：表示拒絕所有請求，一般用于測試 - AlwaysAllow：允許接收所有請求，相當(dāng)于集群不需要授權(quán)流程（Kubernetes默認(rèn)的策略） - ABAC：基于屬性的訪問控制，表示使用用戶配置的授權(quán)規(guī)則對用戶請求進(jìn)行匹配和控制 - Webhook：通過調(diào)用外部REST服務(wù)對用戶進(jìn)行授權(quán) - Node：是一種專用模式，用于對kubelet發(fā)出的請求進(jìn)行訪問控制 - RBAC：基于角色的訪問控制（kubeadm安裝方式下的默認(rèn)選項）
RBAC
RBAC(Role-Based Access Control) 基于角色的訪問控制，主要是在描述一件事情：給哪些對象授予了哪些權(quán)限
其中涉及到了下面幾個概念：
- 對象：User、Groups、ServiceAccount - 角色：代表著一組定義在資源上的可操作動作(權(quán)限)的集合 - 綁定：將定義好的角色跟用戶綁定在一起
RBAC引入了4個頂級資源對象：
- Role、ClusterRole：角色，用于指定一組權(quán)限
- RoleBinding、ClusterRoleBinding：角色綁定，用于將角色（權(quán)限）賦予給對象
Role、ClusterRole
一個角色就是一組權(quán)限的集合，這里的權(quán)限都是許可形式的（白名單）。
# Role只能對命名空間內(nèi)的資源進(jìn)行授權(quán)，需要指定nameapce
kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: dev name: authorization-role rules: - apiGroups: [""] # 支持的API組列表,"" 空字符串，表示核心API群 resources: ["pods"] # 支持的資源對象列表 verbs: ["get", "watch", "list"] # 允許的對資源對象的操作方法列表
# ClusterRole可以對集群范圍內(nèi)資源、跨namespaces的范圍資源、非資源類型進(jìn)行授權(quán)
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: authorization-clusterrole rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]
需要詳細(xì)說明的是，rules中的參數(shù)：
- apiGroups: 支持的API組列表 " ","apps", "autoscaling", "batch" - resources：支持的資源對象列表 "services", "endpoints", "pods","secrets","configmaps","crontabs","deployments","jobs", "nodes","rolebindings","clusterroles","daemonsets","replicasets","statefulsets", "horizontalpodautoscalers","replicationcontrollers","cronjobs" - verbs：對資源對象的操作方法列表 "get", "list", "watch", "create", "update", "patch", "delete", "exec"
RoleBinding、ClusterRoleBinding
角色綁定用來把一個角色綁定到一個目標(biāo)對象上，綁定目標(biāo)可以是User、Group或者ServiceAccount。
# RoleBinding可以將同一namespace中的subject綁定到某個Role下，則此subject即具有該Role定義的權(quán)限
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: authorization-role-binding namespace: dev subjects: - kind: User name: heima apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: authorization-role apiGroup: rbac.authorization.k8s.io
# ClusterRoleBinding在整個集群級別和所有namespaces將特定的subject與ClusterRole綁定，授予權(quán)限
kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: authorization-clusterrole-binding subjects: - kind: User name: heima apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: authorization-clusterrole apiGroup: rbac.authorization.k8s.io
RoleBinding引用ClusterRole進(jìn)行授權(quán)
RoleBinding可以引用ClusterRole，對屬于同一命名空間內(nèi)ClusterRole定義的資源主體進(jìn)行授權(quán)。
一種很常用的做法就是，集群管理員為集群范圍預(yù)定義好一組角色（ClusterRole），然后在多個命名空間中重復(fù)使用這些ClusterRole。
這樣可以大幅提高授權(quán)管理工作效率，也使得各個命名空間下的基礎(chǔ)性授權(quán)規(guī)則與使用體驗保持一致。
# 雖然authorization-clusterrole是一個集群角色，但是因為使用了RoleBinding
# 所以heima只能讀取dev命名空間中的資源
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: authorization-role-binding-ns namespace: dev subjects: - kind: User name: heima apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: authorization-clusterrole apiGroup: rbac.authorization.k8s.io
實戰(zhàn)：創(chuàng)建一個只能管理dev空間下Pods資源的賬號
1) 創(chuàng)建賬號
# 1) 創(chuàng)建證書
[root@master pki]# cd /etc/kubernetes/pki/ [root@master pki]# (umask 077;openssl genrsa -out devman.key 2048)
# 2) 用apiserver的證書去簽署
# 2-1) 簽名申請，申請的用戶是devman,組是devgroup [root@master pki]# openssl req -new -key devman.key -out devman.csr -subj "/CN=devman/O=devgroup" # 2-2) 簽署證書 [root@master pki]# openssl x509 -req -in devman.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out devman.crt -days 3650
# 3) 設(shè)置集群、用戶、上下文信息
[root@master pki]# kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.1.50:6443 [root@master pki]# kubectl config set-credentials devman --embed-certs=true --client-certificate=/etc/kubernetes/pki/devman.crt --client-key=/etc/kubernetes/pki/devman.key [root@master pki]# kubectl config set-context devman@kubernetes --cluster=kubernetes --user=devman
# 切換賬戶到devman
[root@master pki]# kubectl config use-context devman@kubernetes
# 查看dev下pod，發(fā)現(xiàn)沒有權(quán)限
[root@master pki]# kubectl get pods -n dev
# 切換到admin賬戶
[root@master pki]# kubectl config use-context kubernetes-admin@kubernetes
2） 創(chuàng)建Role和RoleBinding，為devman用戶授權(quán)
kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: dev name: dev-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: authorization-role-binding namespace: dev subjects: - kind: User name: devman apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: dev-role apiGroup: rbac.authorization.k8s.io 創(chuàng)建 [root@master pki]# kubectl create -f dev-role.yaml
3) 切換賬戶，再次驗證
# 切換賬戶到devman [root@master pki]# kubectl config use-context devman@kubernetes # 再次查看 [root@master pki]# kubectl get pods -n dev # 為了不影響后面的學(xué)習(xí),切回admin賬戶 [root@master pki]# kubectl config use-context kubernetes-admin@kubernetes
參考
黑馬B站k8s課程https://www.bilibili.com/video/BV1Qv41167ck/
https://gitee.com/yooome/golang/blob/main/k8s%E8%AF%A6%E7%BB%86%E6%95%99%E7%A8%8B-%E8%B0%83%E6%95%B4%E7%89%88/k8s%E8%AF%A6%E7%BB%86%E6%95%99%E7%A8%8B.md
https://www.yuque.com/fairy-era/yg511q/xyqxge
浙公網(wǎng)安備 33010602011771號