集群中Kubernetes资源权限（Kubernetes RBAC授权）

集群中Kubernetes资源权限是基于Kubernetes RBAC能力的授权，通过权限设置可以让不同的用户或用户组拥有操作不同Kubernetes资源的权限。Kubernetes RBAC API定义了四种类型：Role、ClusterRole、RoleBinding与ClusterRoleBinding，这四种类型之间的关系和简要说明如下：

Role：角色，其实是定义一组对Kubernetes资源（命名空间级别）的访问规则。
RoleBinding：角色绑定，定义了用户和角色的关系。
ClusterRole：集群角色，其实是定义一组对Kubernetes资源（集群级别，包含全部命名空间）的访问规则。
ClusterRoleBinding：集群角色绑定，定义了用户和集群角色的关系。

Role和ClusterRole指定了可以对哪些资源做哪些动作，RoleBinding和ClusterRoleBinding将角色绑定到特定的用户、用户组或ServiceAccount上。如下图所示。

图1 角色绑定

在UCS控制台可以授予用户或用户组命名空间权限，可以对某一个命名空间或全部命名空间授权，UCS控制台默认提供如下ClusterRole。

view（只读权限）：对所有命名空间或所选命名空间下大多数Kubernetes资源的RBAC只读权限。
edit（开发权限）：对所有命名空间或所选命名空间下多数Kubernetes资源的RBAC读写权限。
admin（运维权限）：对所有命名空间下大多数Kubernetes资源的RBAC读写权限，对集群节点（node）、存储卷（PV）、命名空间（namespace）、配额（resourcequota）的只读权限。
cluster-admin（管理员权限）：对所有命名空间下Kubernetes资源的RBAC读写权限，以及对集群节点（node）、存储卷（PV）、命名空间（namespace）、配额（resourcequota）的读写权限。

除了使用上述常用的ClusterRole外，您还可以通过定义Role和RoleBinding来进一步对全局资源（如Node、PersistentVolumes、CustomResourceDefinitions等）和命名空间中不同类别资源（如Pod、Deployment、Service等）的增删改查权限进行配置，从而做到更加精细化的权限控制。

注意事项

任何用户创建集群/容器舰队后，UCS会自动为该用户添加该集群/容器舰队的所有命名空间的cluster-admin权限，也就是说该用户允许对该集群/容器舰队以及该集群/容器舰队下所有命名空间中的全部资源进行完全控制。联邦用户由于每次登录注销都会改变用户ID，所以权限用户会显示已删除，此情况下请勿删除该权限，否则会导致鉴权失败。此种情况下建议在UCS为某个用户组创建cluster-admin权限，将联邦用户加入此用户组。
拥有Security Administrator（IAM除切换角色外所有权限）权限的用户（如账号所在的admin用户组默认拥有此权限），才能在UCS控制台命名空间权限页面进行授权操作。

添加资源权限（控制台）

添加权限集群状态需为“运行中”，容器舰队需已开通集群联邦能力。

集群中Kubernetes资源权限是基于Kubernetes RBAC能力的授权，通过权限设置可以让不同的用户或用户组拥有操作不同Kubernetes资源的权限。

登录UCS控制台，在左侧导航栏中选择“权限管理”。
在右边下拉列表中选择要添加权限的集群/容器舰队。
在右上角单击“添加权限”，进入添加权限页面。

在添加权限页面，确认集群/容器舰队名称，选择该集群/容器舰队下要授权使用的命名空间，例如选择“全部命名空间”，选择要授权的用户或用户组，再选择具体权限。

对于没有IAM权限的用户，给其他用户和用户组配置权限时，无法选择用户和用户组，此时支持填写用户ID或用户组ID进行配置。

图2 配置命名空间权限
点击放大

表1 权限类型配置说明
权限类型	权限说明
管理员权限	对所有命名空间下Kubernetes资源的RBAC读写权限，以及对集群节点（node）、存储卷（PV）、命名空间（namespace）、配额（resourcequota）的读写权限须知： UCS FullAccess 不直接具有CCE集群的RBAC权限，需要用户到权限管理页面进行CCE集群授权。
运维权限	对所有命名空间下大多数Kubernetes资源的RBAC读写权限，对集群节点（node）、存储卷（PV）、命名空间（namespace）、配额（resourcequota）的只读权限
开发权限	对所有命名空间或所选命名空间下多数Kubernetes资源的RBAC读写权限
只读权限	对所有命名空间或所选命名空间下大多数Kubernetes资源的RBAC只读权限
自定义权限	权限由您所选择的ClusterRole或Role决定，请在确定所选ClusterRole或Role对各类资源的操作权限后再进行授权，以免子用户或用户组获得不符合预期的权限

其中自定义权限可以根据需要自定义，选择自定义权限后，在自定义权限一行右侧单击新建自定义权限，在弹出的窗口中填写名称并选择规则。创建完成后，在添加权限的自定义权限下拉框中可以选择。

自定义权限分为ClusterRole或Role两类，ClusterRole或Role均包含一组代表相关权限的规则，详情请参见使用RBAC鉴权。

ClusterRole：ClusterRole是一个集群级别的资源，可设置集群的访问权限。
Role：Role用于在某个命名空间内设置访问权限。当创建Role时，必须指定该Role所属的命名空间。

图3 自定义权限

单击“确定”，添加权限。

自定义配置集群中Kubernetes资源权限（kubectl）

kubectl访问集群是通过集群上生成的配置文件（kubeconfig.json）进行认证，kubeconfig.json文件内包含用户信息，根据用户信息的权限判断kubectl有权限访问哪些Kubernetes资源。即哪个用户获取的kubeconfig.json文件，kubeconfig.json就拥有哪个用户的信息，这样使用kubectl访问时就拥有这个用户的权限。而用户拥有的权限就是UCS服务资源权限（IAM授权）与集群中Kubernetes资源权限（Kubernetes RBAC授权）的关系所示的权限。

除了使用cluster-admin、admin、edit、view这4个最常用的clusterrole外，您还可以通过定义Role和RoleBinding来进一步对命名空间中不同类别资源（如Pod、Deployment、Service等）的增删改查权限进行配置，从而做到更加精细化的权限控制。

Role的定义非常简单，指定namespace，然后就是rules规则。如下面示例中的规则就是允许对default命名空间下的Pod进行GET、LIST操作。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default                          # 命名空间
  name: role-example
rules:
- apiGroups: [""]
  resources: ["pods"]                         # 可以访问pod
  verbs: ["get", "list"]                      # 可以执行GET、LIST操作

apiGroups表示资源所在的API分组。
resources表示可以操作哪些资源：pods表示可以操作Pod，其他Kubernetes的资源如deployments、configmaps等都可以操作
verbs表示可以执行的操作：get表示查询一个Pod，list表示查询所有Pod。您还可以使用create（创建）, update（更新）, delete（删除）等操作词。

详细的类型和操作请参见使用 RBAC 鉴权。

有了Role之后，就可以将Role与具体的用户绑定起来，实现这个的就是RoleBinding了。如下所示。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: RoleBinding-example
  namespace: default
  annotations:
    CCE.com/IAM: 'true'    # CCE集群需要该annotation参数，其他类型集群不需要
roleRef:
  kind: Role
  name: role-example
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
  name: 0c97ac3cb280f4d91fa7c0096739e1f8    # user-example的用户ID
  apiGroup: rbac.authorization.k8s.io

这里的subjects就是将Role与IAM用户绑定起来，从而使得IAM用户获取role-example这个Role里面定义的权限，如下图所示。

图4 RoleBinding绑定Role和用户
点击放大

subjects下用户的类型还可以是用户组，这样配置可以对用户组下所有用户生效。

subjects:
- kind: Group
  name: 0c96fad22880f32a3f84c009862af6f7    # 用户组ID
  apiGroup: rbac.authorization.k8s.io

使用IAM用户user-example连接集群，获取Pod信息，发现可获取到Pod的信息。

# kubectl get pod
NAME                                   READY   STATUS    RESTARTS   AGE
deployment-389584-2-6f6bd4c574-2n9rk   1/1     Running   0          4d7h
deployment-389584-2-6f6bd4c574-7s5qw   1/1     Running   0          4d7h
deployment-3895841-746b97b455-86g77    1/1     Running   0          4d7h
deployment-3895841-746b97b455-twvpn    1/1     Running   0          4d7h
nginx-658dff48ff-7rkph                 1/1     Running   0          4d9h
nginx-658dff48ff-njdhj                 1/1     Running   0          4d9h
# kubectl get pod nginx-658dff48ff-7rkph
NAME                     READY   STATUS    RESTARTS   AGE
nginx-658dff48ff-7rkph   1/1     Running   0          4d9h

然后查看Deployment和Service，发现没有权限；再查询kube-system命名空间下的Pod信息，发现也没有权限。这就说明IAM用户user-example仅拥有default这个命名空间下GET和LIST Pod的权限，与前面定义的没有偏差。

# kubectl get deploy
Error from server (Forbidden): deployments.apps is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "deployments" in API group "apps" in the namespace "default"
# kubectl get svc
Error from server (Forbidden): services is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "services" in API group "" in the namespace "default"
# kubectl get pod --namespace=kube-system
Error from server (Forbidden): pods is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "pods" in API group "" in the namespace "kube-system"