Kubernetes v1.6的一个亮点就是RBAC认证特性成为了beta版本。RBAC,基于角色的访问控制(Role-Based Access Control),是用于管理Kubernetes资源访问权限的认证机制。RBAC支持灵活的认证策略配置,使得集群在不重启的情况下就可以升级权限。
  本文重点聚焦在一些有趣的新特性和实践上。

RBAC vs ABAC

  当前Kubernetes已经支持多种认证模式。认证器是一种机制,可以决定用户是否被允许通过Kubernetes API对集群做出一些修改。这会影响到kubectl、系统组件、还有运行在集群中和操纵集群状态的某些应用,如Jenkins的Kubernetes插件,或者是运行在集群中的Helm,它使用Kubernetes API在集群中部署应用。在可用的授权机制中,ABAC和RBAC都是Kubernetes集群的本地机制,都可以对访问策略进行配置。
  ABAC,基于属性的访问控制(Attribute Based Access Control),是一种很强大的概念。然而在Kubernetes的实现中,ABAC难以管理和理解。要改变授权策略,要求有集群master节点的ssh和根文件系统的访问权限。而且,只有在集群的API server重启后,权限变更才会生效。
  RBAC权限策略通过kubectl或者直接使用Kubernetes API来配置。可以通过RBAC来授权用户,从而在不给予用户集群master的ssh访问权限情况下,可以进行资源管理。RBAC策略能够轻松地映射资源和Kubernetes API中使用的操作。
  基于Kubernetes社区的开发力度,未来RBAC应该会取代ABAC。

基本概念

  要理解RBAC,这里有一些基本理念。最核心的,RBAC是一种授权用户对Kubernetes API资源进行不同粒度访问的方式。
  enter description here
  用户和资源的连接是使用RBAC的下面两个对象来定义的。

角色(Roles)

  角色是一系列权限的集合。比如,角色可以被定义为包含pod的读权限和列表(list)权限。ClusterRole(集群角色)和角色很像,但它可以被使用在集群中的任何位置。

角色绑定(Role Bindings)

  角色绑定将角色映射到一个用户或者一组用户,把角色在命名空间中对资源的权限授权给这些用户。ClusterRoleBinding(集群角色绑定)允许授权用户ClusterRole的在整个集群中的授权访问。
  enter description here
  此外,还需要考虑集群角色和集群角色绑定。集群角色和集群角色绑定功能就像角色和角色绑定一样,只是有着更宽的使用范围。集群用户、集群用户绑定和用户、用户绑定之间的准确区别,详见Kubernetes doc

Kubernetes中的RBAC

  RBAC现在已经被深度集成在Kubernetes中,并使用它授权给系统组件使用。系统角色system为前缀,因此可以轻易地识别出来。

$  kubectl get clusterroles --namespace=kube-system
NAME                    KIND
admin                   ClusterRole.v1beta1.rbac.authorization.k8s.io
cluster-admin           ClusterRole.v1beta1.rbac.authorization.k8s.io
edit                    ClusterRole.v1beta1.rbac.authorization.k8s.io
kubelet-api-admin       ClusterRole.v1beta1.rbac.authorization.k8s.io
system:auth-delegator   ClusterRole.v1beta1.rbac.authorization.k8s.io
system:basic-user       ClusterRole.v1beta1.rbac.authorization.k8s.io
system:controller:attachdetach-controller ClusterRole.v1beta1.rbac.authorization.k8s.io
system:controller:certificate-controller ClusterRole.v1beta1.rbac.authorization.k8s.io
...

  扩充了RBAC的系统角色,仅使用RBAC就能管理运行Kubernetes集群所需的权限。
  在从ABAC到RBAC的权限迁移期间,一些在ABAC授权的deployment中默认使能的权限,在RBAC中被识别为是没有必要的,权限会在RBAC中被降级。可能会影响到服务帐户的权限的负载。在ABAC配置下,使用pod映射token来授权API server的pod请求有着很高的权限。一个具体的例子,当使能ABAC时,下面的curl命令会返回一个JSON格式的正确结果,而只使能RBAC时则会返一个错误。

$ kubectl run nginx --image=nginx:latest
$ kubectl exec -it $(kubectl get pods -o jsonpath='{.items[0].metadata.name}') bash
$ apt-get update && apt-get install -y curl
$ curl -ik \
  -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
  https://kubernetes/api/v1/namespaces/default/pods

  在从ABAC迁移为RBAC的过程中,Kubernetes集群中运行的任何应用,只要和Kubernetes API交互,都可能被权限迁移所影响。
  为了使ABAC到RBAC的迁移尽量平滑,你可以在创建Kubernetes v1.6集群时,同时使能ABAC和RBAC授权。当同时使能ABAC和RBAC时,如果任一授权策略授以访问权限,则都被会授予资源权限。然而,然而在这种配置下,被赋予了太宽容的权限,在完全的RBAC环境下可能无法工作。
  现在,RBAC完全足够,ABAC的支持未来应该考虑被弃用。在可预见的未来,它应该还会保存在Kubernetes中,不过开发主要集中在RBAC上了。
  在Google Cloud Next会议上,有两篇涉及到Kubernetes v1.6中BRAC相关改变的演讲,可通过这里这里来查看相关部分。如果要查看更多关于Kubernetes v1.6使用RBAC的详细信息,阅读完整的RBAC文档