RBAC在Kubernetes上的支持

Posted 2021-04-16 容器时代

导读：

Kubernetes 1.6的重大特性之一就是RBAC的引入（现为Beta版）。RBAC即基于角色的访问控制，是围绕Kubernetes资源管理权限的授权机制。RBAC允许在不重启集群的基础上配置灵活的授权策略。本文将专注于这些有趣的能力和最佳实践。

1

RBAC vs ABAC

当下，对于Kubernetes而言有这几种授权机制。授权指的是一种用来决定谁可以通过Kubernetes API对集群进行某些操作的技术。它会影响到诸如kubectl、系统组件以及在集群内运行的应用和操作集群的状态等，比如使用了Kubernetes插件的Jenkins，或者运行在集群里的Helm，它可以使用Kubernetes API来向集群里安装应用。除去可用的授权技术。ABAC和RBAC是Kubernetes自身的授权机制，满足可配置的权限策略。

ABAC，基于属性的访问控制，是一种非常强大的理念。然而，被Kubernetes实现后变得难以管理和理解。它需要Master节点的ssh和root文件系统访问权限来实现授权策略的改变。对于影响到集群API的权限改变，服务器一定要进行重启。

RBAC，通过kubectl或Kubernetes API直接进行配置权限策略。用户可以被授权来使用RBAC自身进行权限的改变，这代表着无需ssh登录到集群Master就可以完成资源管理。通过Kubernetes API，RBAC策略轻而易举地映射到资源和对应的操作上。

基于Kubernetes 社区专注在开发的重点，更推荐使用RBAC。

2

基本概念

RBAC背后只有很少的一些基础概念。它的核心是，RBAC是一种通过Kubernetes API资源粒度进行用户授权的方法。

RBAC使用两个对象定义了用户和资源之间的连接。

A

角色

角色是一组权限的集合。例如，一个角色可以定义为读取Pod的权限和查看Pod列表的权限。ClusterRole就像角色，但是可以用在集群的任何地方。

B

角色绑定

角色绑定是将角色映射到一个或一组用户上，将这个角色的权限授予这个命名空间下的这些用户。ClusterRoleBinding允许用户授权为ClusterRole来访问整个集群。

另外，需要考虑集群角色和集群角色绑定。集群角色和集群角色绑定功能跟就像角色和角色绑定，除了范围更广外，集群角色和集群角色绑定与角色和角色绑定间的微小差异在下面的链接了进行了详细描述。

https://kubernetes.io/docs/admin/authorization/rbac/#rolebinding-and-clusterrolebinding

3

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的集群所有必备的权限。

在将ABAC迁移到RBAC的过程中，被视为非必要的ABAC的一些默认开启的权限，在RBAC里被相应地削弱。最可能影响到集群负载的是对service account的访问权限。通过ABAC的权限配置，来自一个pod的请求通过挂载到pod的token会拥有更多的权限。一个典型的例子，最后的curl命令将会返回一个JSON格式的结果，当ABAC启用时，如果只要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

你运行在Kubernetes里的任何与Kubernetes API进行交互的应用都有可能受到来自ABAC到RBAC转换的影响。

为了平滑地迁移，你可以创建一个同时开启ABAC和RBAC授权的K8s1.6的集群。当ABAC和RBAC都启用，并只有在两个策略都允许访问的时候，对一个资源的授权才算开启。然而，这样的配置开启了最高的授权性，于是就不可能通过RBAC进行完全的控制了。

现在，RBAC完全够用，ABAC的支持应该会逐渐废弃掉。它允许保留在Kubernetes里，在可预见的未来里，开发的重心会在RBAC。

在Google Cloud Next大会上两场不同的演讲都提到了Kubernetes 1.6里与RBAC相关的改变。跳转到这里（https://www.youtube.com/watch?v=Cd4JU7qzYbE#t=8m01s）和这里（https://www.youtube.com/watch?v=18P7cFc6nTU#t=41m06s）。更多的信息请参考RBAC文档（https://kubernetes.io/docs/admin/authorization/rbac/）。

4

加入社区

• Slack sig-auth channel

• 加入每两周的meeting SIG-Auth会，太平洋时间11:00 AM

感谢你的支持和贡献。

5

加入容器时代

（微信群已满，请添加k8stimes或者扫下面二维码添加好友，小助手会将您拉入群聊）

6

架构真经