k8s--apiserver授权策略----RBAC

k8s API Server 讲解：https://www.cnblogs.com/du-z/p/16140319.html

RBAC授权模式讲解

RBAC（Role-Based Access Control，基于角色访问控制）在k8s的1.5版本引入，在1.6版本升级为Bate版本（公测版），在1.8版本是升级为GA（General Availability）（正式版）。作为kubeadm安装方法的默认选项，足见其重要程度。相对于其他控制方式，新的RBAC具有如下优势：

1. 对集群中的资源和非资源权限均有完整的覆盖
2. 整个RBAC完全由几个API对象完成，同其他API对象一样，可以用kubectl或API运行进行操作
3. 可以在运行时进行调整，无需重启APIserver

要使用RBAC授权模式，需要在API Server启动参数中加上--authorization-mode=RBAC

---

RBAC授权策略的原理和用法

RBAC的API资源对象说明

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

角色（Role）

一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。在一个命名空间中，可以用Role来定义一个角色，如果时集群级别的，就需要使用ClusterRole；Role只能对namespace内的资源进行授权，
示例：

[root@k8s-master yaml]# cat Roletest.yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]       #apiGroups可以为空字符串，但不可以为空
  resources: ["pods"]
  verbs: ["get","watch","list"]


#rules中的参数说明
1. apiGroups：支持的API组列表，[""]空字符串表示核心API群
2. resources：支持的资源对象列表，例如pods、deployments、jobs等
3. verbs：对资源对象的操作方法表，API的REST操作方法，例如：get、watch、list、delete、replace、patch等

集群角色（ClusterRole）

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

1. 集群范围的资源，例如：Node
2. 非资源型的路径，例如："/healthz"
3. 包含全部命名空间的资源，例如：pods （用于kubectl get pods --all-namespaces 这样的操作授权）

[root@k8s-master yaml]# cat ClusterRoletest.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: test
rules:
- apiGroups: [""]    #apiGroups可以为空字符串，但不可以为空
  resources:
  - secrets
  verbs:
  - get
  - watch
  - list

角色绑定（RoleBinding）和集群角色绑定（ClusterRoleBinding）

Rolebinding或ClusterRoleBinding用来把一个角色绑定到一个目标上，绑定的目标可以是User（用户）、Goup（组）或者Service Account ；使用RoleBinding为某个namespace授权，使用ClusterRoleBinding为集群范围内授权
RoleBinding可以引用Role进行授权；下面例子中的RoleBinding将在default命名空间中把pod-reader角色授予用户du，这一操作让du读取default命名空间中的Pod

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata: 
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: du
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RoleBinding也可以引用ClusterRole，对属于同一namespace内的ClusterRole定义的资源主体进行授权；一种常见的做法是集群管理员对集群范围预先定义好一组ClusterRole，然后在多个namespace中重复使用这些ClusterRole
例如，如下虽然secret-reader是一个ClusterRole，但是因为使用了RoleBinding，所以用户du只能读取development命名空间中的secret

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata: 
  name: read-secrets
  namespace: development
subjects:
- kind: User
  name: du
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: CluserRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding绑定的角色只能是ClusterRole，用于集群级别或者多所有namespace都有生效的授权；如下示例中，允许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: CluserRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io