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

Kubernetes 中的 RBAC 支持

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

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

Kubernetes 1.6 版本的一大亮点是 RBAC 授权器功能已进入 *beta* 阶段。RBAC（基于角色的访问控制）是一种授权机制，用于管理 Kubernetes 资源权限。RBAC 允许配置灵活的授权策略，这些策略可以在不重启集群的情况下进行更新。

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

RBAC 与 ABAC

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

ABAC（基于属性的访问控制）是一个强大的概念。然而，在 Kubernetes 中的实现中，ABAC 难以管理和理解。它需要对集群主 VM 进行 ssh 和根文件系统访问才能进行授权策略更改。权限更改生效需要重启集群 API 服务器。

RBAC 权限策略直接使用 kubectl 或 Kubernetes API 进行配置。用户可以使用 RBAC 本身被授权进行授权策略更改，从而无需授予集群主节点 SSH 访问权限即可委托资源管理。RBAC 策略易于映射到 Kubernetes API 中使用的资源和操作。

基于 Kubernetes 社区的开发重点，今后应优先使用 RBAC 而非 ABAC。

基本概念

理解 RBAC 有几个基本概念。其核心是，RBAC 是一种授予用户对 Kubernetes API 资源精细访问权限的方式。

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

角色 (Roles)
角色是权限的集合。例如，一个角色可以定义为包含对 Pod 的读取权限和对 Pod 的列表权限。ClusterRole 就像一个角色，但可以在集群中的任何地方使用。

角色绑定 (Role Bindings)
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 新功能的深度文章。