写在前面

上周Docker公司发布了Docker企业版的最新测试版。毫无疑问，此版本最重要的功能之一就是为Swarm 和Kubernetes 群集提供了统一的管理控制界面。在制作这个版本的时候，团队深知不能只在Kubernetes上加装一个GUI（图形用户界面）就发布出去。团队希望可以找到一种简化并保护在Kubernetes 节点上部署应用程序的方法。

其中一个方法就是基于角色的访问控制（RBAC）。Docker EE 17.06引入了增强的基于角色的访问控制（RBAC）解决方案，它可以为多个团队和用户提供灵活、细粒度的访问控制。虽然Kubernetes在1.6版本中首次引入了基于角色的访问控制（RBAC）解决方案，但在即将发布的新版本中，我们扩展了Docker EE现有RBAC支持，使其能更好的支持Kubernetes。

如果您还不熟悉RBAC 的工作原理，请参阅文章：

《3分钟带您了解Docker EE的访问控制原理（内附实操案例）》
《分享丨3分钟了解Docker 企业版的三个实用新功能》

创建高度自定义的角色

除了Docker EE中的五个自定义身份验证角色(view only、full control、none等) 之外，管理员还可以使用33种不同的操作类别来创建自定义角色。而且，这些类别都涵盖了多个不同的设置。对于管理员来说，这意味着他们可以为一些用户设置一组合理的默认角色，或者在需要的地方创建高度自定义的角色。

混合编排的RBAC示例

如上图所示，我们有三个人Katherine、Saavni 和Kahlil。Katherine 是我们的容器管理员，她可以访问群集上所有的Kubernetes 命名空间和swarm 资源。Kahlil 则是我们的初级管理员，他不需要管理运行的Kubernetes资源，但是他需要对生产系统上运行的基于Kubernetes的应用程序有一定程度的了解。Saavni也是如此，只是她专注于基于Swarm的应用程序。

对于Khalil来说，Katherine设置了一个只允许用户列出Pods的自定义角色。然后，她创建了一个授予Kahlil这个角色的权限，但它仅限于“prod-web”的命名空间。

接下来，Katherine创建了一个自定义角色，她允许用户列出swarm服务，并将该角色权限授予Saavni作为“prod_db”集合。

正如您所希望的那样，Khalil仅限于他所属的命名空间（prod-web），他所能做的就是看看哪个Pods正在运行。他既不能修改那些正在运行的Pods，也不能创建新的Pods。当然，他也看不到任何可能在其他命名空间中运行的Pods。无论Khalil是通过Docker EE的通用控制界面还是通过命令行使用Docker EE客户端软件包来访问Kubernetes集群，这些限制都会生效。

而对于Saavni 来说，同样的限制也应用于在我们的prod-db集合中运行的Swarm服务。此外，值得注意的一点是，Saavni无法使用任何Kubernetes资源，而Khalil也无法使用任何Swarm资源。

这是一个简单、形象的例子，它可以让您很好地了解在Docker EE中RBAC所提供的灵活性，包括使用统一的管理模式为Kubernetes 和 Swarm 提供RBAC 支持，并且控制这些工作是否可以通过GUI或CLI来管理应用程序。

Kubernetes资源认证

那么，如何在Kubernetes资源的覆盖下工作呢？Docker EE利用Kubernetes webhook认证模型，它可以验证外部来源的所有请求。在Docker EE中，我们使用控制界面中的RBAC 控制器——eNZi。每个Kubernetes请求，无论是通过CLI还是GUI发布，都会根据Docker EE的authN / authZ数据库进行验证，然后根据您的需要来选择接受或拒绝。

Kubernetes 和Docker EE 访问控制的整合只是即将发布的新功能之一。我们还做了很多工作，将Kubernetes与Docker Trusted Registry（以及添加DTR镜像中转）整合在一起，还对HTTP路由功能进行了重大改进。我将在未来几周内发布相关文章，敬请关注。

测试版下载地址：https://beta.docker.com/

备注：文章转自Docker公司官方官方公众号，原文作者为 Mike Coleman Docker公司