Kubernetes中的RBAC支持

编者注:这篇文章是 系列深入文章 Kubernetes 1.6的新功能

的亮点之一 Kubernetes 1.6 发布是RBAC授权者功能移至 贝塔。 RBAC是基于角色的访问控制,是用于管理Kubernetes资源周围权限的授权机制。 RBAC允许配置灵活的授权策略,该策略可以在不重新启动群集的情况下进行更新。

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

RBAC和ABAC

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

ABAC,基于属性的访问控制,是一个强大的概念。但是,如在Kubernetes中实施的那样,ABAC难以管理和理解。它要求在群集的主VM上具有ssh和根文件系统访问权限,以进行授权策略更改。为了使权限更改生效,必须重新启动集群API服务器。

RBAC权限策略直接使用kubectl或Kubernetes API配置。可以授权用户使用RBAC本身进行授权策略更改,从而可以委派资源管理而无需放弃对群集主服务器的ssh访问。 RBAC策略可以轻松映射到Kubernetes API中使用的资源和操作。

基于Kubernetes社区专注于他们的开发工作的位置,应该比ABAC更倾向于RBAC。

基本概念

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

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

的角色
角色是权限的集合。例如,可以定义一个角色以包括对Pod的读取权限和对Pod的列表权限。 ClusterRole就像角色一样,但是可以在集群中的任何位置使用。

角色绑定
RoleBinding将Role映射到一个或一组用户,从而将该角色的权限授予那些用户对该名称空间中的资源的访问权限。通过ClusterRoleBinding,可以授予用户一个ClusterRole,以便在整个集群中进行授权。

此外,还需要考虑群集角色和群集角色绑定。群集角色和群集角色绑定的功能类似于角色和角色绑定,但它们具有更广泛的范围。本章介绍了确切的区别以及群集角色和群集角色绑定与角色和角色绑定的交互方式。 Kubernetes文档.

RBAC在Kubernetes中

RBAC现在已深度集成到Kubernetes中,并由系统组件用来授予它们运行所需的权限。 系统角色 通常以系统为前缀:这样就可以轻松识别它们。

➜  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的令牌从Pod发出的请求向API服务器进行身份验证具有广泛的授权。作为一个具体的示例,此序列末尾的curl命令将在启用ABAC时返回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)" \

 //kubernetes/api/v1/namespaces/default/pods

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

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

至此,RBAC已足够完善,因此应考虑弃用ABAC支持。在可预见的将来,它仍将保留在Kubernetes中,但发展关注的重点是RBAC。

在Google Cloud 下一页会议上的两次不同演讲都谈到了Kubernetes 1.6中与RBAC相关的更改,跳至相关部分 这里这里。有关在Kubernetes 1.6中使用RBAC的更多详细信息,请阅读全文 RBAC文档.

参与其中

如果您想贡献或只是提供反馈意见并制定路线图, 加入我们的社区。对安全性和RBAC相关对话特别感兴趣,请通过以下渠道之一参与:

感谢您的支持和贡献。阅读有关Kubernetes 1.6新增功能的更多深入文章 这里.

-Google的软件工程师Greg Castle和CJ Cullen,Jacob Simpson