本文超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否未变得不正确。

Kubernetes 中的 RBAC 支持

作者：Jacob Simpson (Google), Greg Castle (Google), CJ Cullen (Google) |

编者注：这篇文章是关于 Kubernetes 1.6 新功能的一系列深度文章的一部分。

Kubernetes 1.6 版本的亮点之一是 RBAC 授权功能进入 _测试_ 阶段。RBAC，基于角色的访问控制，是一种用于管理 Kubernetes 资源权限的授权机制。RBAC 允许配置灵活的授权策略，无需重启集群即可更新。

本文的重点是突出一些有趣的新功能和最佳实践。

RBAC 与 ABAC

目前，Kubernetes 可以使用多种授权机制。授权器是决定谁被允许使用 Kubernetes API 对集群进行哪些更改的机制。这会影响 kubectl、系统组件以及集群中运行并操纵集群状态的某些应用程序，例如带有 Kubernetes 插件的 Jenkins，或在集群中运行并使用 Kubernetes API 安装应用程序的 Helm。在可用的授权机制中，ABAC 和 RBAC 是 Kubernetes 集群本地的机制，允许可配置的权限策略。

ABAC，基于属性的访问控制，是一个强大的概念。但是，正如在 Kubernetes 中实现的那样，ABAC 难以管理和理解。它需要对集群的主虚拟机的 ssh 和根文件系统进行访问才能更改授权策略。为了使权限更改生效，必须重新启动集群 API 服务器。

RBAC 权限策略使用 kubectl 或直接使用 Kubernetes API 进行配置。可以使用 RBAC 本身授权用户进行授权策略更改，从而可以在不放弃对集群主服务器的 ssh 访问权限的情况下委派资源管理。RBAC 策略很容易映射到 Kubernetes API 中使用的资源和操作。

根据 Kubernetes 社区关注其开发工作的方向，未来应优先选择 RBAC 而不是 ABAC。

基本概念

RBAC 背后有一些基本概念，它们是理解它的基础。RBAC 的核心是授予用户对 Kubernetes API 资源的粒度访问权限的方式。

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

角色
角色是权限的集合。例如，可以定义一个角色以包括对 pod 的读取权限和对 pod 的列表权限。ClusterRole 与 Role 类似，但可以在集群中的任何位置使用。

角色绑定
RoleBinding 将角色映射到一个或一组用户，将该角色的权限授予这些用户以访问该命名空间中的资源。ClusterRoleBinding 允许用户被授予 ClusterRole 以在整个集群中进行授权。

此外，还需要考虑集群角色和集群角色绑定。集群角色和集群角色绑定的功能类似于角色和角色绑定，只是它们的范围更广。确切的区别以及集群角色和集群角色绑定如何与角色和角色绑定交互，请参阅 Kubernetes 文档。

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 授权集群的部署中默认启用的某些权限被认为过于宽泛，并且在 RBAC 中缩小了范围。最有可能影响集群上工作负载的区域是服务帐户可用的权限。使用宽松的 ABAC 配置，使用 pod 挂载令牌向 API 服务器进行身份验证的 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

在 Kubernetes 集群中运行的任何与 Kubernetes API 交互的应用程序都可能会受到从 ABAC 转换为 RBAC 时权限更改的影响。

为了平滑地从 ABAC 过渡到 RBAC，您可以创建同时启用 ABAC 和 RBAC 授权器 的 Kubernetes 1.6 集群。当同时启用 ABAC 和 RBAC 时，如果任一授权策略授予访问权限，则授予对资源的授权。但是，在这种配置下，将使用最宽松的授权器，并且将无法使用 RBAC 完全控制权限。

目前，RBAC 已经足够完善，以后应将 ABAC 支持视为已弃用。它在可预见的未来仍将保留在 Kubernetes 中，但开发注意力集中在 RBAC 上。

Google Cloud Next 大会上的两场不同的演讲都谈到了 Kubernetes 1.6 中与 RBAC 相关的变化，请跳转到相关部分此处和此处。有关在 Kubernetes 1.6 中使用 RBAC 的更多详细信息，请阅读完整的 RBAC 文档。

参与进来

如果您想贡献或只是想提供反馈并推动路线图，请加入我们的社区。如果您特别关注安全性和 RBAC 相关的对话，请通过以下渠道之一参与：

感谢您的支持和贡献。请阅读更多关于 Kubernetes 1.6 新功能的深度文章，请点击此处。