K8S的RBAC资源

RBAC授权规则是通过四种资源来进行配置的，他们可以分为两组：

• Role(角色)和ClusterRole(集群角色)，他们指定了在资源上可以执行那些动作。
• RoleBingding(角色绑定)和ClusterRole(集群角色绑定)，他们将角色绑定到特定的用户、组或者ServiceAccounts上

角色定义了可以做什么操作，而绑定定义了谁可以做这些操作

Role(角色)和ClusterRole(集群角色)，或者RoleBingding(角色绑定)和ClusterRole(集群角色绑定)之间的区别在于Role(角色)和RoleBingding(角色绑定)的是namespace(命名空间)的资源，而ClusterRole(集群角色)和ClusterRole(集群角色绑定)是集群级别的资源，而不是命名空间的。

1、Role和ClusterRole

Role（角色）是一系列权限的集合，例如一个角色可以包含读取 Pod 的权限和列出 Pod 的权限。

Role 只能用来给某个特定 namespace 中的资源作鉴权，对多 namespace 和集群级的资源或者是非资源类的 API（如 /healthz）使用 ClusterRole。

如果你希望在名字空间内定义角色，应该使用 Role； 如果你希望定义集群范围的角色，应该使用 ClusterRole。

赋予的权限可以精确到某个资源创建的资源

1、role

Role示例：授予对 的读访问权限

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
  resources: ["pods","pods/exec"]   # "需要赋予权限的资源，这里为pods，如果想要获得执行权限等可以为 pods/exec 的格式"
  # resourceNames: ["my-pod"]       # 已经创建好的名为 my-pod 的pod权限
  verbs: ["get", "watch", "list"]   # 允许的权限

2、ClusterRole

ClusterRole 示例

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
  name: secret-reader
rules:
- apiGroups: [""]      
  resources: ["secrets"]
  verbs: ["get", "watch", "list"] 

权限参数：

• get 和 list：读取权限

• watch：动态获取的操作，相当于 -w

• delete：删除权限

2、RoleBinding 和 ClusterRoleBinding

RoleBinding 把角色（Role 或 ClusterRole）的权限映射到用户或者用户组，从而让这些用户继承角色在 namespace 中的权限。

ClusterRoleBinding 让用户继承 ClusterRole 在整个集群中的权限。

1、RoleBinding

RoleBinding 示例（引用 Role）

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

 2、ClusterRoleBinding

ClusterRoleBinding 示例（引用ClusterRole）

apiVersion: rbac.authorization.k8s.io/v1
# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 secrets
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # 'name' 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

3、总结Role、ClusterRole、Rolebinding和ClusterRoleBinding的组合

访问的资源	使用的角色类型	使用绑定的绑定类型
集群级别	ClusterRole	ClusterRoleBinding
非资源型URL	ClusterRole	ClusterRoleBinding
在任何命名空间中的资源	ClusterRole	ClusterRoleBinding
在具体命名空间中的资源（在多个命名空间中重用这个相同的ClusterRole）	ClusterRole	RoleBinding
在具体命名空间中的资源（Role必须在每个命名空间中定义好）	Role	RoleBinding

4、默认的Rolebinding和ClusterRoleBinding

Kubernetes提供了一组默认的Cluster和ClusterRoleBingding，每次API服务重新启动时都会更新他们，这保证了在错误的删除角色和绑定，或者kuberneter使用了不同的集群角色和绑定配置时，左右的默认角色和绑定都会被重新刷新创建

查看默认的集群角色和绑定

# 查看默认的 clusterrolebindings
kubectl get clusterrolebindings

#查看默认的 clusterrole
kubectl get clusterroles

view、edit、admin、cluster-admin在ClusterRole是重要的角色，他们应该绑定到用户定义pod中的ServiceAccount上。

1、view CusterRole允许对资源的只读访问

允许读取一个命名空间中的大部分资源，除了Role、RoleBingding和Secret，Secret中可能包含一个认证的token，如果允许读取，将是一个非常危险。

2、edit CusterRole允许对资源的修改

允许修改一个命名空间中的资源，同时允许读取和修改Sercret，但是不允许访问Role和RoleBingding，这是为了防止权限扩散。

3、admin CusterRole赋予一个命名空间的全部控制权

赋予一个命名空间中的资源完全控制权，这个CusterRole赋予的。有这个CusterRole的主体可以读取和修改命名空间中的任何资源，除了ResourceQuoat和命名空间资源本身。edit和admin ClusterRole 之间的主要区别是能否在命名空间中查看和修改Role和RoleBinding。

4、cluster-admin CusterRole得到完全的控制

可以获得kubernetes集群完全控制权，admin CusterRole 不允许用户修改命名空间的ResourceQuoat和命名空间资源本身，cluster-admin CusterRole可以允许用户这样做。

5、实战：赋予不同用户的不同权限

• 需求：

  • 用户jojo可以查看default、kube-system下Pod的日志

  • 用户dio可以在default下的Pod中执行命令，并且可以删除Pod

查看namespace

[root@master ~]# cat namespace-read.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-readonly
rules:
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

可以删除Pod

[root@master ~]# cat pod-delete.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-delete
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - delete

在pod中执行命令

[root@master ~]# cat pod-exec.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-exec
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
- apiGroups:
  - ""
  resources:
  - pods/exec
  verbs:
  - create

查看pod的日志

[root@master ~]# cat pod-log.yaml    
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-log
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - pods/log
  verbs:
  - get
  - list
  - watch

创建用户

kubectl create sa jojo -n kube-user
kubectl create sa dio -n kube-user

赋予jojo用户权限

kubectl create rolebinding a-jojo --clusterrole=pod-log --serviceaccount=kube-user:jojo -n default
kubectl create rolebinding b-jojo --clusterrole=pod-log --serviceaccount=kube-user:jojo -n kube-system

赋予dio用户权限

kubectl create rolebinding a-dio --clusterrole=pod-delete   --serviceaccount=kube-users:dio --namespace=default
kubectl create rolebinding b-dio --clusterrole=pod-exec   --serviceaccount=kube-users:dio --namespace=default