Kubernetes角色访问控制RBAC和权限规则(Role+ClusterRole)
文章转载自: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