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

Kubernetes 中的 RBAC 支持

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

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

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

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

RBAC vs 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 至关重要。其核心在于，RBAC 是一种授予用户对 Kubernetes API 资源 细粒度访问权限的方式。

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

Role（角色）
Role 是一组权限的集合。例如，可以定义一个角色，使其包含对 Pod 的读取权限和对 Pod 的列表权限。ClusterRole 类似于 Role，但可以在集群中的任何地方使用。

RoleBinding（角色绑定）
RoleBinding 将 Role 映射到用户或一组用户，授予这些用户在特定命名空间内对该 Role 所定义资源的权限。ClusterRoleBinding 允许用户在整个集群范围内被授予 ClusterRole 的授权。

此外，还需要考虑 ClusterRole 和 ClusterRoleBinding。ClusterRole 和 ClusterRoleBinding 的功能类似于 Role 和 RoleBinding，只是作用范围更广。关于 ClusterRole 和 ClusterRoleBinding 与 Role 和 RoleBinding 的具体区别以及如何交互，请参阅 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 使用挂载的 token 向 API 服务器认证的请求具有广泛的授权。举个具体例子，当启用 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 新特性的深度文章这里。