Kubernetes v1.6是如何支持RBAC的

这篇文章将为大家详细讲解有关Kubernetes v1.6是如何支持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上了。

关于“Kubernetes v1.6是如何支持RBAC的”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。