Rancher 2.0正式版已全面发布。Rancher 2.0是一个开源的Kubernetes管理平台，为企业用户提供Kubernetes-as-a-Service (Kubernetes即服务)，并且能够实现多Kubernetes集群的统一纳管。这一创造性的统一纳管功能将解决生产环境中企业用户可能面临的基础设施不同的困境。Rancher 2.0是业界第一个能统一纳管来自Google（GKE）、Amazon（EKS）和Azure（AKS）等公有云上托管的Kubernetes服务的平台。

在Rancher 2.0中，我们重点关注的一个领域就是身份认证和授权。在Kubernetes强大的基础功能之外，Rancher 2.0格外专注于简易性和易用性，它是一个既强大又易于使用的系统。Rancher 2.0让管理员能够管理多集 群环境，同时还能够帮助用户快速启动并运行环境。本文将从身份认证和授权的角度，介绍Rancher能够给组织、管理员和用户带来哪些好处。

在深入讨论Rancher能带来什么之前，我们将先在本文前半部分简要回顾一下Kubernetes身份认证与授权相关的概念。如果想深入了解这些概念的更多细节，可参考Kubernetes官方的文档：
https://kubernetes.io/docs/ad...
https://kubernetes.io/docs/ad...

身份认证

想要理解Kubernetes的身份认证以及Rancher如何对这一功能进行拓展加强，那么就必须要先理解下面这几个关键的概念：身份认证策略、用户和组，以及用户模拟。

身份认证策略（Authentication Strategies）

Kubernetes提供了多种身份认证策略，包括：客户端证书、OpenID Connect令牌、Webhook令牌认证、身份认证代理、服务账户令牌等等。每一种策略都有它的优缺点，但最终它们都要负责判断申请API调用的用户的身份，这样Kubernetes RBAC框架才可以决定是否要授权给申请调用者，让其执行其请求的操作。

尽管已经有大量可用的策略能解决大多数情况，但需要注意的是，配置它们需要精确控制Kubernetes控制平台的配置和部署。像Google这样的云服务提供商通常会将其锁定，防止用户按照自己的喜好配置它。而Rancher 2.0解决了这个问题，我们会在后面讨论。

用户和组（Users and Groups）

Kubernetes有两种类型的用户：服务账户和普通用户。其中服务账户完全由Kubernetes管理，而“普通”用户则完全不受Kubernetes的管理。事实上，Kubernetes没有用户或组的API资源。因此最终，普通用户和组在用户绑定中表现为晦涩的对象，用以做权限的检查。

用户模拟（User Impersonation）

Kubernetes中的用户模拟是一个用户（或服务账户）扮演另一个用户的能力。一个subject必须明确地具有“模拟”特权，才能够执行对其他用户的模拟。虽然这可能看起来是一个相当模糊和细微的功能，但它对于Rancher如何实现身份验证至关重要。

授 权

要理解Kubernetes中的授权以及Rancher如何构建它，还必须理解这些概念：roles（角色）、clusterRoles（集群角色）、roleBindings（角色绑定）和clusterRoleBindings（集群角色绑定）。从命名就能看出，这些概念之间非常相似，但适用于不同的范围。

roles是命名空间的一个作用域，这意味着它是在命名空间中创建的，并且只能由该命名空间内的roleBinding引用。roleBinding在用户、组或者服务账户（在Kubernetes中称为subject）和命名空间中的role之间创建关联。它有效地说明了用户 X在命名空间Z中具有Y角色，或者我们给一个具体的例子：Sarah能够在“dev”这个命名空间中进行部署的创建、更新和删除。

clusterRole的样子和作用方面与role非常相似。唯一的区别是它没有命名空间。clusterRole是在集群层面定义的。同样的，clusterRoleBinding是roleBinding的无命名空间版本。当你创建clusterRoleBinding时，意味着你为特定的subject赋予了可用于整个集群、每个命名空间的权限。

需要注意的是：roleBinding可以引用role或者clusterRole。无论它引用的role类型是什么，权限只适用于rolebinding所在的命名空间。

有了对Kubernetes基础概念的理解，我们接下来可以开始讨论Rancher是如何使用和增强它们，创建出强大且易于使用的身份认证和授权系统的。

Rancher的身份认证和授权

Rancher 2.0的主要目标之一，是帮助系统管理员运行多个异构的Kubernetes集群。这些集群可以是来自于云提供商或本地解决方案的任何组合，这就产生了许多有趣的身份认证和授权挑战。其中我们确定并解决的关键问题是：

如何在不同类型的集群中拥有统一的身份验证体验？
如何管理跨集群的用户和权限？
如何启用“自动服务”方式使用集群，同时保持适当的控制水平？
如何防止用户在低信任环境中获得对底层基础设施资源的过多访问？

每一种挑战我们接下来都会讨论。

统一认证

为了实现跨集群的统一身份认证体验，我们将Rancher服务器设计成所有身份验证的中心点。管理员只需在Rancher中配置一次身份认证工具，它就可以应用到任何地方。之后，在所有访问Kubernetes集群的请求面前，Rancher都相当于一个身份验证代理。

由于大多数云提供商不公开必要的hooks用来插入Kubernetes的各种认证策略，因此Rancher的身份验证代理位于外部，独立于集群而存在。它执行必要的身份认证工作，收集用户的身份和任何的组，然后通过用户模拟将请求转发到适当的集群，以充当该用户。正因为认证方法是标准的Kubernetes无记号令牌，因此Rancher的代理可以无缝地插入kubectl等现有的Kubernetes工具中。

用户管理

正如之前所说，Kubernetes没有一等用户的理念，而Rancher有。用户可以由管理员手动创建，也可以在GitHub等身份认证工具那里按需创建（Github在头一次打开时需要用户登录）。我们从Rancher 1.x中吸取了经验教训，在默认情况下，本地身份认证是开启且始终开启的。这样以来，Rancher在默认情况下是安全的，并且在身份认证工具出现故障时提供了访问Rancher的备份机制。

创建一个驻留在中央Rancher服务器上的一等用户资源可以带来很多好处。例如，管理员现在可以查看和操作任何特定用户对所有集群的访问权限。它还使Rancher能够管理特定于每个用户的资源，如系统首选项、API令牌和节点模板。最后，它使得管理用户权限变得更简单，我们将在下文讨论。

RBAC 授权

在深入讨论授权之前，我们必须先介绍和讨论一个关键的Rancher概念：项目。项目是可以应用于各种策略的命名空间的集合。这些策略（并非所有的策略都进入了我们的初始GA版本）包括RBAC、网络访问、pod安全性和配额管理。项目“拥有”命名空间，以及为项目所做的任何RBAC绑定都适用于项目中的所有命名空间。这个关键概念允许将集群有效地分割和组织成更小、更易于管理的块(chunks)。

Rancher有效地为用户提供了三层roles或权限：全局、集群和项目层级。全局定义了你可以在单个集群之外执行的操作。对于大多数人来说，这可以认为是将用户或组的子集标记为“管理员”，其余部分标记为“普通”用户。除了可以完全访问所有集群外，管理员还可以执行配置身份验证提供者和管理用户等操作。而普通用户只能访问他们拥有或已被邀请的集群或项目。

Rancher RBAC直接建立在Kubernetes RBAC之上（前面讨论的role和binding概念）。如果你了解Kubernetes的概念，Rancher RBAC就很容易理解。实际上，我们在Rancher服务器中创建roles和bindings模板，并将它们传播到适当的集群。因此，我们在Rancher API中有以下自定义资源：roleTemplates,clusterRoleTemplateBindings以及projectRoleTemplateBindings。管理员可以管理roleTemplates和集群，而项目所有者可以使用它们授予对其集群或项目不同程度的访问权限。

自助服务访问

Rancher默认支持自助服务访问模式，帮助组织授权用户从Kubernetes获得更多信息。普通用户可以创建自己的集群并成为其所有者。他们是该集群的管理员，可以将其他用户和组设成集群成员，授予他们访问权限。一旦用户成为了集群成员，它就可以在集群中创建项目并成为这些项目的所有者。作为项目所有者，可以邀请其他人称为项目成员或所有者。项目成员能够在他们所属的项目中创建命名空间并部署工作负载。你可以看到，这个自助服务系统是如何创建的，并让用户能够快速且轻松地启动和运行。

而这种方式下，也有常见的问题：“如果我不想让用户创建集群或项目，该怎么办？”

这一问题有几个答案。首先，如果他们不能访问基础设施资源（意味着他们无法创建虚拟机或者没有组织云提供商的密钥），那么他们无法创建功能集群。其次，我们的RBAC系统是可配置的，这样管理员可以在默认情况下明确地选择用户可以做什么。最后，用户可以直接被添加到项目中，而不需要创建明确的集群成员。这意味着他们将不能创建新的项目，而只能使用那些他们被明确添加进去的项目。通过这种方式，Rancher使组织能够授权它们的用户，同时给予管理员他们所需要的控制。

控制基础设施层级的访问

许多用例会要求用户限制他们可以部署的容器类型以及这些容器允许执行的内容。为了解决这个问题，Kubernetes搬出了podSecurityPolicies。这是一个非常重要的功能，但它的原始形式却很难正确使用。关于它是如何工作的，以及他能做什么，这些讨论操出了本文的范围，但我们可以这么总结它：podSecurityPolicies允许管理员限制可以部署在集群中的pod类型。用一个简单和容易理解的例子来说就是，它可以防止用户部署特权容器，这为许多用例解决了大的安全漏洞。

Rancher不仅支持podSecurityPolicies，而且增强了该功能，大大提高了可用性。使用Rancher，管理员可以在全局定义一组用于所有集群的podSecurityPolicy模板。然后，集群所有者可以将默认策略分配给集群，并在每个项目基础上管理例外情况。换句话说，集群所有者可以说：“除了少数特殊项目外，所有项目都有一个限制策略，阻止他们部署特权容器。”此功能可用于安全的多租户集群。

总 结

通过本文，希望你能看到我们在Rancher 2.0中对身份验证和授权的关注。所有这一切都建立在Kubernetes基本概念的基础之上。秉承Rancher一贯关注可用性及简单性的原则，Rancher 2.0对Kubernetes身份认证和授权进行了更多增强和扩展，以创建出更加强大的组合，帮助企业用户更简单快捷落地Kubernetes。