详解K8S与Rancher 2.0内的身份认证与受权

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/admin/authentication/

https://kubernetes.io/docs/admin/authorization/rbac/

身份认证

想要理解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。