RBAC基础:

对集群中的资源和非资源权限均有完整的覆盖
整个RBAC完全由几个API对象完成，同其他API对象一样，可以用kubectl或API进行操作
可以在运行时进行调整，无需重启API Server
要使用RBAC授权模式，需要在API Server的启动参数中加上--authorization-mode=RBAC

基础理论:

RBAC引入了4个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding。同其他API资源对象一样，用户可以使用kubectl或者API调用等方式操作这些资源对象。

角色(Role)

一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。在一个命名空间中，可以用角色来定义一个角色，如果是集群级别的，就需要使用ClusterRole了。角色只能对命名空间内的资源进行授权，下面的例子中定义的角色具备读取Pod的权限:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
    namespace: default
    name: pod-reader

rules:
- apiGroups: [""]  # 空字符串表示核心API群
  resource: ["pods"]
  verbs: ["get", "watch", "list"]

rules中的参数说明:

apiGroup：支持的API组列表，例如：APIVersion: batch/v1、APIVersion: extensions:v1、apiVersion:apps/v1等
resources：支持的资源对象列表，例如：pods、deployments、jobs等
verbs：对资源对象的操作方法列表，例如：get、watch、list、delete、replace、patch等

集群角色(ClusterRole)

集群角色除了具有和角色一致的命名空间内资源的管理能力，因其集群级别的范围，还可以用于以下特殊元素的授权

集群范围的资源，例如Node
非资源型的路径，例如/healthz
包含全部命名空间的资源，例如pods
下面的集群角色可以让用户有权访问任意一个或所有命名空间的secrets：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:  # name: secret-reader
  # ClusterRole不受限于命名空间，所以省略了namespace name的定义

rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

角色绑定(RoleBinding)/集群角色绑定(ClusterRoleBinding)

角色绑定或集群角色绑定用来把一个角色绑定到一个目标上，绑定目标可以是User、Group或者Service Account。使用RoleBinding为某个命名空间授权，ClusterRoleBinding为集群范围内授权。
RoleBinding可以引用Role进行授权，下例中的RoleBinding将在default命名空间中把pod-reader角色授予用户jane，可以让jane用户读取default命名空间的Pod：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default

subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RoleBinding也可以引用ClusterRole，对属于同一命名空间内ClusterRole定义的资源主体进行授权。一种常见的做法是集群管理员为集群范围预先定义好一组角色(ClusterRole)，然后在多个命名空间中重复使用这些ClusterRole .使用RoleBinding绑定集群角色secret-reader，使dave只能读取development命名空间中的secret：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development

subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

集群角色绑定中的角色只能是集群角色，用于进行集群级别或者对所有命名空间都生效的授权。允许manager组的用户读取任意namespace中的secret

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

资源的引用方式:

多数资源可以用其名称的字符串来表达，也就是Endpoint中的URL相对路径，例如pods。然后，某些Kubernetes API包含下级资源，例如Pod的日志(logs)。Pod日志的Endpoint是GET /api/v1/namespaces/{namespaces}/pods/{name}/log。

Pod是一个命名空间内的资源，log就是一个下级资源。要在一个RBAC角色中体现，则需要用斜线/来分割资源和下级资源。若想授权让某个主体同时能够读取Pod和Pod log，则可以配置resources为一个数组：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

资源还可以通过名字(ResourceName)进行引用。在指定ResourceName后，使用get、delete、update、patch动词的请求，就会被限制在这个资源实例范围内。例如下面的声明让一个主体只能对一个叫my-configmap的configmap进行get和update操作：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 namespace: default
 name: configmap-updater
rules:
- apiGroups: [""]
 resources: ["configmap"]
 resourceNames: ["my-configmap"]
 verbs: ["update", "get"]

常见的role:

允许读取核心API组中Pod的资源：

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

允许读写"extensions"和"apps"两个API组中的deployment资源

rules:
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允许读写pods及读写jobs

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  resources: ["jobs"]  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允许读取一个名为my-config的ConfigMap(必须绑定到一个RoleBinding来限制到一个namespace下的ConfigMap)：

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

读取核心组的node资源(Node属于集群级别的资源，必须放在ClusterRole中，并使用ClusterRoleBinding进行绑定)：

rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

允许对非资源端点/healthz及其所有子路径进行GET/POST操作(必须使用ClusterRole和ClusterRoleBinding)：

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"]
  verbs: ["get", "post"]

常用的角色绑定主体

用户名Alice@example.com

subjects:
- kind: User
  name: "Alice@example.com"
  apiGroup: rbac.authorization.k8s.io

组名frontend-admins

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

所有Service Account

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

所有认证用户

subjects:
- kind: Group
  name: system:authentication
  apiGroup: rbac.authorization.k8s.io

所有未认证用户

subjects:
- kind: Group
  name: system:unauthentication
  apiGroup: rbac.authorization.k8s.io

全部用户

subjects:
- kind: Group
  name: system:authentication
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthentication
  apiGroup: rbac.authorization.k8s.io

k8s默认的绑定:

API Server会创建一套默认的ClusterRole和ClusterRoleBinding对象，其中很多是以system:为前缀的，以表明这些资源属于基础架构，对这些对象的改动可能造成集群故障。所有默认的ClusterRole和RoleBinding都会用标签kubernetes.io/bootstrapping=rbac-defaults进行标记。

常见的系统角色如下：

image.png

有些默认角色不是以system:为前缀的，这部分角色是针对用户的，其中包含超级用户角色cluster-admin，有的用于集群一级的角色cluster-status，还有针对namespace的角色admin、edit、view:

image.png

k8s-RBAC