Kubernetes角色访问控制RBAC和权限规则

基于角色的访问控制（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

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

原文链接：https://blog.csdn.net/BigData_Mining/article/details/88849696