文章轉載自：https://blog.csdn.net/BigData_Mining/article/details/88849696
基於角色的訪問控制（Role-Based Access Control, 即”RBAC”）使用”rbac.authorization.k8s.io” API Group實現授權決策，允許管理員通過Kubernetes API動態配置策略。
基於RBAC配置User權限，包括操作（get、create、list、delete、update、edit、watch、exec）資源：
Pods
PV
ConfigMaps
Deployments
Nodes
Secrets
Namespaces
資源與api group關聯（如pods屬於core api group，deployments屬於apps api group）。
在RBAC中的幾個概念：
Rules：規定一組可以在不同api group上的資源執行的規則（verbs）
Role與ClusterRoles：都是包括一組規則（rules）兩者不同在於，Role針對的是一個namespace中，ClusterRoles針
對整個集群
Subject：有三種Subjects，Service Account、User Account、Groups，參照官方文檔主要區別是User Account針對
人，Service Accounts針對運行在Pods中運行的進程。
RoleBindings與ClusterRoleBindins：將Subject綁定到Role或ClusterRoles。其區別在於：RoleBinding將使規則在命
名空間內生效，而ClusterRoleBinding將使規則在所有命名空間中生效。
RBAC API所定義的四種類型
Role與ClusterRole
在RBAC API中，一個角色定義了一組特定權限的規則。namespace范圍內的角色由Role對象定義，
而整個Kubernetes集群范圍內有效的角色則通過ClusterRole對象實現。
Role
Role對象只能用於授予對某一namespace中資源的訪問權限。
以下示例表示在“default” namespace中定義一個Role對象，用於授予對資源pods的讀訪問權限，綁定到該Role的用戶則具有get/watch/list pod資源的權限:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # 空字符串""表明使用core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
為了更容易對API進行擴展，Kubemetes 使用API Groups (API組)進行標識。APIGroups 以及REST URL中的路徑進行定義。當前支持兩類API groups。
Core Groups (核心組)，也可以稱為Legacy Groups，該組的REST路徑位於/api/v1, 作為 Kubernetes 最核心的 API，
它是沒有“組”的概念，例如 ”v1“，在資源對象的定義中表示為”apiVersion: v1“。
具有分組信息的API，以/apis/$GROUP_NAME/$VERSIONURL路徑進行標識，在資源對象的定義中表示為
apiVersion: $GROUP_NAME/$VERSION（例如，apiVersion: batch/v1）。已支持的 API 組詳細列表請參閱
Kubernetes API reference。
ClusterRole
ClusterRole對象可以授予整個集群范圍內資源訪問權限， 也可以對以下幾種資源的授予訪問權限：
- 集群范圍資源（例如節點，即node）
- 非資源類型endpoint（例如”/healthz”）
- 跨所有namespaces的范圍資源（例如pod，需要運行命令kubectl get pods --all-namespaces來查詢集群中所有的pod)
以下示例中定義了一個名為pods-reader的ClusterRole，綁定到該ClusterRole的用戶或對象具有用對集群中的資源pods的讀訪問權限：
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
# 鑒於ClusterRole是集群范圍對象，所以這里不需要定義"namespace"字段
name: pods-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
RoleBinding與ClusterRoleBinding
角色綁定將一個角色中定義的各種權限授予一個或者一組用戶，則該用戶或用戶組則具有對應綁定的Role或ClusterRole定義的權限。
角色綁定包含了一組相關主體（即subject, 包括用戶——User、用戶組——Group、或者服務賬戶——Service Account）以及對被授予角色的引用。 在某一namespace中可以通過RoleBinding對象授予權限，而集群范圍的權限授予則通過ClusterRoleBinding對象完成。
- RoleBinding
- RoleBinding可以將同一namespace中的subject（用戶）綁定到某個具有特定權限的Role下，則此subject即具有該Role定義的權限。
下面示例中定義的RoleBinding對象在”default” namespace中將”pod-reader”角色授予用戶”Caden”。 這一授權將允許用戶”Caden”從”default” namespace中讀取pod。
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: Caden
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
ClusterRoleBinding
ClusterRoleBinding在整個集群級別和所有namespaces將特定的subject與ClusterRole綁定，授予權限。
下面示例中所定義的ClusterRoleBinding 允許在用戶組”pods-reader”中的任何用戶都可以讀取集群中任何namespace中的pods。
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-pods-global
subjects:
- kind: Group
name: pods-reader
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: pods-reader
apiGroup: rbac.authorization.k8s.io
此外，RoleBinding對象也可以引用一個ClusterRole對象用於在RoleBinding所在的namespace內授予用戶對所引用的ClusterRole中 定義的namespace資源的訪問權限。這一點允許管理員在整個集群范圍內首先定義一組通用的角色，然后再在不同的名字空間中復用這些角色。
例如，盡管下面示例中的RoleBinding引用的是一個ClusterRole對象，但是用serviceaccount ”reader-dev”（即角色綁定主體）還是只能讀取”development” namespace中的pods（即RoleBinding所在的namespace）。
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-pods
namespace: development # 這里表明僅授權讀取"development" namespace中的資源，若不定義該字段，則表示整個集群的Pod資源都可訪問
subjects:
- kind: ServiceAccount
name: reader-dev
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: pod-reader
namespace: kube-system
相關命令行工具
獲取並查看Role/ClusterRole/RoleBinding/ClusterRoleBinding的信息
kubectl get role -n kube-system
查看kube-system namespace下的所有role
kubectl get role <role-name> -n kube-system -o yaml
查看某個role定義的資源權限
kubectl get rolebinding -n kube-system
查看kube-system namespace下所有的rolebinding
kubectl get rolebinding <rolebind-name> -n kube-system -o yaml
查看kube-system namespace下的某個rolebinding詳細信息（綁定的Role和subject）
kubectl get clusterrole
查看集群所有的clusterrole
kubectl get clusterrole <clusterrole-name> -o yaml
查看某個clusterrole定義的資源權限詳細信息
kubectl get clusterrolebinding
查看所有的clusterrolebinding
kubectl get clusterrolebinding <clusterrolebinding-name> -o yaml
查看某一clusterrolebinding的詳細信息
有兩個kubectl命令可以用於在命名空間內或者整個集群內授予角色。
kubectl create rolebinding
在某一特定名字空間內授予Role或者ClusterRole。示例如下：
a) 在名為”acme”的名字空間中將admin ClusterRole授予用戶”bob”：
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
b) 在名為”acme”的名字空間中將view ClusterRole授予服務賬戶”myapp”：
kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
kubectl create clusterrolebinding
在整個集群中授予ClusterRole，包括所有名字空間。示例如下：
a) 在整個集群范圍內將cluster-admin ClusterRole授予用戶”root”：
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
b) 在整個集群范圍內將system:node ClusterRole授予用戶”kubelet”：
kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet
c) 在整個集群范圍內將view ClusterRole授予名字空間”acme”內的服務賬戶”myapp”：
kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp