kubernetes中的RBAC

kubernetes1.6版本中最引入注意的是RBAC授权机制进入 Beta阶段,RBAC(基于角色的权限访问控制)是控制访问kubernetes资源的权限.RBAC允许灵活的配置授权策略,而不需要重启集群.本文重点描述RBAC机制带来的能力以及最佳实践.

RBAC对比ABAC

在Kubernetes中当前存在很多授权的机制可以使用,授权是一种机制来决定了谁来权限来通过kubernete API来修改集群的状态.影响到的事务包括kubectl,系统组件,允许特定运行的容器.比如集成Kubernetes插件的Jenkins, 运行在集群中的Helm,将会使用Kubernetes API来在集群中安装应用.除了可以使用的授权机制,ABAC和RBAC是Kubernetes集群的本地机制，允许配置许可策略。
ABAC(基于属性的访问控制)是一个强大的概念,然而,如果在Kuberntes实施的时候,ABAC难以管理和理解.它需要集群的master节点上的ssh和根文件系统访问权限才能进行授权策略更改。 要使权限更改生效，必须重新启动集群API服务器。
RBAC的权限策略可以通过Kubectl或者直接通过Kubernetes API来配置.用户可以被认证. 用户可以被授权使用RBAC本身进行授权策略更改，从而可以委派资源管理，而不会丢弃对集群主机ssh访问。 RBAC策略可轻松映射到Kubernetes API中使用的资源和操作。
基于Kubernetes社区正在集中精力开展研发工作，RBAC优先于ABAC。

基本概念

在RBAC里面有很多基本的概念,这些概念是理解RBAC的基础.它核心的功能是,RBAC是分配用户的访问Kubernetes API中涉及资源

在RBAC中定义的用户以及资源连接是通过在RBAC中使用了两类主题:
-角色
角色是权限的集合。 例如，可以定义角色以包括pod上的读取权限和pod的列表权限。 ClusterRole就像一个角色，但可以在集群中的任何地方使用。
-角色绑定
RoleBinding将角色映射到一个用户或一组用户，授予该角色对这些用户对该命名空间中资源的权限。 ClusterRoleBinding可以让用户在整个集群中授予ClusterRole进行授权。

另外还有要考虑的集群角色和集群角色绑定。 集群角色和集群角色绑定的功能类似于角色和角色绑定，但范围更广。 Kubernetes文档涵盖了与角色和角色绑定与集群角色和集群角色绑定的确切差异。

Kubernetes中的RBAC

RBAC现在已深入整合到Kubernetes中，并被系统组件用于授予他们所需的权限。 系统角色通常以system为前缀：可以轻松识别。

kubectl get clusterroles --namespace=kube-systemNAME                    KINDadmin ClusterRole.v1beta1.rbac.authorization.k8s.iocluster-admin ClusterRole.v1beta1.rbac.authorization.k8s.ioedit ClusterRole.v1beta1.rbac.authorization.k8s.iokubelet-api-admin ClusterRole.v1beta1.rbac.authorization.k8s.iosystem:auth-delegator ClusterRole.v1beta1.rbac.authorization.k8s.iosystem:basic-user ClusterRole.v1beta1.rbac.authorization.k8s.iosystem:controller:attachdetach-controller ClusterRole.v1beta1.rbac.authorization.k8s.iosystem:controller:certificate-controller ClusterRole.v1beta1.rbac.authorization.k8s.io

已经扩展了RBAC系统角色，以覆盖仅使用RBAC运行Kubernetes集群的必要权限。

在从ABAC到RBAC的权限转换中，在许多部署ABAC授权集群中默认启用的一些权限被确定为不必要的范围，并在RBAC中被限定。 最有可能影响集群工作负载的区域是可用于服务帐户的权限。 使用允许的ABAC配置，使用pod安装的令牌的端口向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,你可以创建kuberntes1.6集群的时候使用ABAC和RBAC认证开启.当ABAC和RBAC都开启的时候,如果任一授权策略授权访问权限，则授予资源授权。 然而，在这种配置下，使用最宽容的授权器，并且不可能使用RBAC来完全控制权限。
在这一点上，RBAC已经足够完整了，ABAC的支持应该被视为不推荐使用。 在可预见的将来，它仍将保留在Kubernetes，但发展重点则集中于RBAC。
在Google Cloud Next会议上的两个不同的谈话，涉及到了Kubernetes的RBAC相关变化1.6。 有关在Kubernetes 1.6中使用RBAC的更多详细信息，请阅读完整的RBAC文档。

参与其中

如果您想贡献或只是帮助提供反馈并推动路线图,加入社区,对安全性和RBAC相关对话特别感兴趣，请通过以下渠道参与：
在 [ Slack sig-auth ] 频道上跟我们聊天
在每周四的上午11:00参加SIG-Auth会议

感谢

– Jacob Simpson, Greg Castle & CJ Cullen, Software Engineers at Google http://blog.kubernetes.io/2017/04/rbac-support-in-kubernetes.html