理解 Kubernetes的RBAC

Swire

前些天撸了Kubernetes 1.6 和 1.7 两个版本, 发现官方对它最大的改进在于权限. 自版本 1.6 起,Kubernetes 默认由 RBAC 授权.

在kube-apiserver这个服务的配置项中,有一参数项为--authorization-mode,这便是设置授权的模式,值项有:

  • AlwaysAllow 总是允许

  • AlwaysDeny 总是拒绝

  • ABAC 基于属性的权限验证

  • Webhook 基于网络事件的回调钩子

  • RBAC 基于角色的权限验证

  • Node 基于节点验证. Kubernetes 1.7 新增

其他的不是重点,这里只需要理解 RBAC 这个权限授权模式.

之前发布的 1.8 的 alpha2 版本中,RBAC 的API 已经从 rbac.authorization.k8s.io/v1beta1 移到了 rbac.authorization.k8s.io/v1了,表明 RBAC 已经作为正式稳定的功能了,并且官方的 CHANGELOG 中大量的更改项都与 RBAC 有关,现今网上许多关于Kubenretes 构建的同样是基于 RBAC, 看样子这应该是现在与未来在 KuberNetes 中主流鉴权模式了.

什么是RBAC

RBAC 即 Role-Based Access Control.

RBAC 在用户和权限之间引入了角色(Role)的概念.用户在进行相关的命令或资源操作的时候,就会需要一个或多个权限的验证.每个用户可以关联一个或多个角色,可以根据实际的业务需求而关联相应的角色,从而实现粒度细且操作灵活的权限管理.

Kubernetes的RBAC

Kubernetes 中存在两种角色:

  • Role 普通角色. 定义在单一的 namespace 内部,且只能对该 namespace 内部的资源或操作有效.

  • ClusterRole 集群角色. 作用范围是整个集群的资源和操作.

在 Kubernetes 中,RBAC 管理的资源对象有:ConfigMap,Deployment,Job,Namespace,Node,Pods,Persistents,Replicasets,Secrets,Service,Statefulsets等等,囊括了绝大部分Kind.

而命令操作的对象有:create,delete,edit,exec,get,list,patch,update,watch.

Role

创建一个Role

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # 不指定 namespace 就默认为 default
  namespace: default
  name: rbac-test
rules:
#- apiGroups: [""] # 如果为空表示就只有 core API group
- apiGroups:
  - core
  - apps
  - batch
  resources: ["pods","job","daemonset"]
  verbs: ["get", "watch", "list"]

以上的配置表明在 default 的 namespace 下创建一个名为 rbac-test 的角色,这个角色可操作的api集合包括core,batch,apps,分别对应下属的pods,job,daemonset这些资源,并只允许使用get,watch,list这些操作.

角色已经建立,接下来就是使用该角色了.

需要指定 subject 绑定 role .至于 subject 它是一个 list , 其中可以是组或用户或多个用户加组等组合.

用户的创建,可以参考之前文章中创建 kubectl 操作的 admin 用户流程.

假设现在已经创建了一个名为 test 的账号.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-role-bind
  namespace: default
subjects:
- kind: User
  name: test # 用户名区分大小写
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # 这里只许填 Role 或 ClusterRole 之一
  name: rbac-test # 必须匹配之前创建的Role或ClusterRole的名称
  apiGroup: rbac.authorization.k8s.io

如此一来,就完成了角色与用户的绑定,用户就有了操作相应资源的权限.

ClusterRole

ClusterRole 的创建类似 Role,只不过就是名称不同,并且资源相应多了,比如多了Cluster APIS 资源集的权限.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # ClusterRole 没有 namespace 的概念,作用范围是全集群
  name: clusterRole-test
rules:
- apiGroups: ["core","apps"]
  resources: ["ConfigMap","Secrets"]
  verbs: ["get","watch","list"]

对象绑定角色,假设存在一个名为 testg 的用户组,绑定 testg 组让该组下的所有用户都有权限.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: clusterRole-test-bind
  # namespace: default # 如果不指定 namespace 则作用整个范围,若指定 namespace 则绑定的用户只有在当前的 namespace 内有效.
subjects:
- kind: Group
  name: testg
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: clusterRole-test
  apiGroup: rbac.authorization.k8s.io

参考: RBAC Authorization