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资源进行不同粒度访问的方式。
　　
　　用户和资源的连接是使用RBAC的下面两个对象来定义的。

角色（Roles）

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

角色绑定（Role Bindings）

　　角色绑定将角色映射到一个用户或者一组用户，把角色在命名空间中对资源的权限授权给这些用户。ClusterRoleBinding（集群角色绑定）允许授权用户ClusterRole的在整个集群中的授权访问。
　　
　　此外，还需要考虑集群角色和集群角色绑定。集群角色和集群角色绑定功能就像角色和角色绑定一样，只是有着更宽的使用范围。集群用户、集群用户绑定和用户、用户绑定之间的准确区别，详见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文档。