怎么分析K8S与Rancher 2.0内的身份认证与授权

共计 4475 个字符，预计需要花费 12 分钟才能阅读完成。

这篇文章将为大家详细讲解有关怎么分析 K8S 与 Rancher 2.0 内的身份认证与授权，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

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 能够给组织、管理员和用户带来哪些好处。

身份认证

想要理解 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 模板。然后，集群所有者可以将默认策略分配给集群，并在每个项目基础上管理例外情况。换句话说，集群所有者可以说：“除了少数特殊项目外，所有项目都有一个限制策略，阻止他们部署特权容器。”此功能可用于安全的多租户集群。

关于怎么分析 K8S 与 Rancher 2.0 内的身份认证与授权就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。