红帽 OpenShift 和微服务架构中的身份验证和授权

安全性是基于容器的架构的关键组成部分之一。

它涉及很多方面（只需单击此处查看官方 OpenShift 文档中的主题列表即可了解详情），但其中最基本的要求是身份验证和授权。在本文中，我将阐述 Kubernetes 和红帽 OpenShift 中身份验证和授权的运作机制。另外，我还将介绍 Kubernetes 生态系统不同层之间的交互机制，包括基础架构层、Kubernetes 层和容器化应用层。

什么是身份验证和授权？

简单来说，计算机系统中的身份验证就是回答“您是谁？”，而授权则是回答“现在我已确认您的身份，您可以做些什么？”

根据我的经验，Kubernetes 中这一主题之所以难以理解，很大程度上是因为用户、API、容器、Pod 等众多组件之间的交互机制错综复杂。在讨论身份验证时，您必须首先明确涉及哪些组件。您是要对 Kubernetes 集群进行身份验证？还是讨论微服务试图访问环境内另一个微服务的场景？或是位于集群外部的云资源？亦或是某个端点（云资源、系统或人员）试图访问和使用集群上运行的某个应用？

使用 OAuth 2.0 和 OIDC 进行身份验证和授权

假设用户正尝试访问某个端点。用户可以是：

• 真人
• 非人类帐户（应用 Pod、系统组件、软件管道或者物理或逻辑实体）

端点可以是：

• API
• 软件（如数据库）
• 物理或虚拟服务器

当端点收到来自用户的请求时，它必须能够理解：

• 谁在发送该请求（这属于身份验证部分）
• 此用户有权执行的操作（这属于授权部分）

在 Kubernetes 官方文档中，用一整个章节介绍了身份验证。该文档的核心要点在于：Kubernetes 中的身份验证指对发往 Kubernetes API 服务器的 API 请求进行身份验证的过程。这些请求可以从终端或 GUI 中的 kubectl 或 oc 命令发出，也可以通过 API 调用发出，但最终所有内容都将发送到 API 服务器。

尽管有许多身份验证技术和协议可用（如 LDAP、SAML、Kerberos 等），但最有效和最常见的 API 身份验证方法是结合使用 OAuth 2.0 和 OpenID Connect（OIDC）。

OAuth 2.0 是一种授权协议（而非身份验证协议），旨在授予对一组资源（如远程 API 或用户数据）的访问权限。为此，OAuth 2.0 使用了访问令牌，这段数据表示授权代表最终用户访问资源。

OpenID Connect（OIDC）是一种身份验证协议，通过在该协议基础上提供身份层来扩展 OAuth 2.0 框架。它提供了一种机制来请求特定用户信息（如姓名或电子邮件地址），并允许用户授予或拒绝对此信息的访问权限。该协议对 OAuth2 的主要扩展是：在返回访问令牌时，会返回一个称为 ID 令牌的额外字段。此令牌是 JSON Web 令牌（JWT），具有由服务器签名的特定字段，如用户的电子邮件。

下图显示了当用户尝试使用 kubectl 命令在 Kubernetes 集群中配置一组操作时执行的步骤。整个过程比较复杂，但官方文档中有详细记录。

标题：Kubernetes 文档中展示身份验证流程的流程图

1. 首先，您需要登录身份提供商
2. 身份提供商将向您提供 access_token、id_token 和 refresh_token
3. 使用 kubectl 时，可通过 --token 参数传入您的 id_token，或者将令牌添加到 kubeconfig
4. kubectl 将名为“授权”的标题中的 id_token 发送到 API 服务器
5. API 服务器验证 JWT 签名是否有效，id_token 是否尚未过期，以及用户是否已获得此事务的授权
6. API 服务器返回对 kubectl 的响应，后者向您提供反馈

由于您的 id_token 包含验证您的身份所需的所有数据，Kubernetes 不需要与身份提供商进一步交互。这是一种高度可扩展的身份验证解决方案，尤其是在每个请求都是无状态的情况下。

什么是基于角色的访问控制（RBAC）？

基于角色的访问权限控制（RBAC）是一种根据企业组织内各个用户的角色来管理计算机或网络资源访问权限的方法。例如，平台上的系统管理员可能有权对整个环境进行修改（可能会影响集群上的每个应用）。但是，如果您只负责管理集群上的一个应用，您可能只能对该应用进行修改。

下图显示了两类示例用户。绿色图标表示属于人力资源团队的用户，而黑色图标表示平台管理员。人力资源团队用户只能访问人力资源应用组下的资源，但平台管理员可以访问平台内的任何资源。

在授权步骤中，人力资源用户被授予绿色令牌，管理员被授予黑色令牌。作为与端点（Kubernetes 集群或 OpenShift API）交互的一部分，每个用户都会在其请求中添加自己的令牌（绿色或黑色）。根据此令牌，集群就能知道每个用户可以访问哪些应用。

传输层和端点

触达 Kubernetes 端点的最常见传输机制是传输层安全性（TLS），它为 HTTPS 提供加密隧道。

如果您是 Linux 或 Windows 虚拟机的系统管理员，那么您可以通过 SSH 或 RDP 访问这些端点。这些协议会对您（用户）和端点（Linux 或 Windows 服务器）之间的流量进行加密。类似地，在处理 API、软件或第三方软件即服务（SaaS）时，最常见的传输机制就是 TLS。

如何在端点和用户之间建立安全加密会话不在本博客的讨论范围内，但它依赖于隧道和密钥（或证书），这些隧道和密钥用于验证端点（用户和/或端点），并对端点之间发送的数据包进行加密和解密。

Kubernetes 和 OpenShift 访问层级

只要理解了身份验证、授权和传输这三个概念，就会知道它们没那么复杂。然而，在任何 IT 环境中，都有多个层需要考虑，而这正是复杂性和混乱的根源所在。

在 Kubernetes 架构中，有三个主要层：

• 基础架构层：计算、存储和网络。这一层可以是公共云、本地或托管数据中心，或者是所有这些环境的混合
• Kubernetes 层：负责托管和管理所有容器化应用
• 容器化应用：构成特定应用的容器组。这些应用可能包括现成的商业应用（COTS）、独立软件供应商（ISV）、内部开发的应用，或者上述各项的任意组合

每个层都提供身份验证和授权功能且需要进行身份验证和授权。

基础架构层中的身份验证和授权

基础架构层的用户通常是需要访问特定组件（存储、网络、计算或虚拟化）的系统管理员。要访问这一层（即上图中黑色显示的底层），管理用户通常使用存储、网络或计算节点（iLO、iDRAC 等）的专用接口，通过 SSH 连接到服务器。身份验证机制可以是 RADIUS/TACACS（网络）、LDAP 或 Kerberos（服务器和存储）的组合，或者其他特定于域的身份验证机制。

有趣的是，同一基础架构管理用户可能会使用 OpenShift（蓝色层）上托管的应用（在绿色层）来帮助他们执行活动。

例如，网络管理堆栈可能是在 OpenShift 上运行的容器化应用。但在这种情况下，管理员用户在功能上是一个试图访问应用（本例中为网络管理堆栈）的普通（绿色）用户。这一层中的身份验证和授权机制有所不同。例如，与应用的连接可通过 TLS/SSL 连接实现，并且可能需要凭据才能访问网络管理堆栈控制台。

OpenShift 中的身份验证和授权

倒数第二层是蓝色层（即通常与 OpenShift 或 Kubernetes 交互），意味着与 Kubernetes API 服务器通信。无论是人类用户还是非人类用户，无论他们使用的是 GUI 控制台还是终端，皆是如此。最终，与 OpenShift 或 Kubernetes 的所有交互都要通过 API 服务器实现。

OAuth2/OIDC 组合非常适合 API 身份验证和授权，因此 OpenShift 具有内置的 OAuth2 服务器。作为此 OAuth2 服务器配置的一部分，必须添加受支持的身份提供程序。身份提供程序帮助 OAuth2 服务器确认用户是谁。这一部分配置完成后，OpenShift 即准备好对用户进行身份验证。

对于通过身份验证的用户，OpenShift 会创建访问令牌并将该令牌返回给用户。此令牌称为“OAuth 访问令牌”。用户可以在每次与 OpenShift API 交互过程中使用这些 OAuth 访问令牌，直到该访问令牌过期或被撤销。

用户和服务帐户

用户可以是人类，也可以是非人类。在 OpenShift 中，任何给定用户都可能具有概念上不同的角色：

• 普通用户：人类与 Kubernetes 集群交互
• 系统用户：人类（例如，平台管理员）和非人类集群组件（例如，镜像仓库、各种控制平面节点和应用节点）
• 其他非人类用户：包括服务帐户。它们通常代表需要与 Kubernetes API 交互的应用（在集群内部或外部）。例如，使用 GitLab、GitHub 和 Tekton 的管道，将会使用服务帐户与 OpenShift 交互

在 OpenShift 中，用户和服务帐户可以划分为多个群组。在管理授权策略以同时向多个用户授予权限时，划分群组会非常有帮助。例如，您可以允许某个群组访问项目中的对象，而不是单独向每个用户授予访问权限。

一个用户可以被分配到一个或多个群组，每个群组代表特定的用户集合。大多数企业组织已拥有现成的用户群组（例如，在 Active Directory 服务器中）。您可以将 LDAP 记录与内部 OpenShift 群组记录同步。

基于角色的访问控制（RBAC）和授权

当用户成功通过身份验证并收到 OAuth2 访问令牌后，系统就会根据 RBAC 授予该用户一组访问权限。RBAC 对象决定是否允许用户对资源执行指定的操作。RBAC 定义可以是集群范围的，也可以是项目范围的。

RBAC 通过以下要素进行管理：

• 规则：针对一组对象所允许的操作集合。这些操作统称为 CRUD：创建、读取、更新和删除。它们是持久存储的基本操作。在 RESTful API 上下文中，它们分别对应 HTTP 协议的 POST、GET、PUT 或 PATCH 和 DELETE。例如，用户或服务帐户可能有权创建 Pod
• 角色：规则集合。您可以将用户和群组关联或绑定到多个角色
• 绑定：用户及群组与角色之间的关联

OpenShift 提供预定义的角色（cluster-admin、basic user 等）。下图很好地展示了使用规则、角色和绑定的 RBAC（摘自 OpenShift 文档）。

OpenShift 层内资源的身份验证和授权

Kubernetes 层内的资源（通常是 Pod）可能需要访问权限才能执行以下任一操作：

• 与 Kubernetes API 交互
• 与托管资源的主机（基础架构层）交互
• 与集群外部的资源（如云资源）交互

与 Kubernetes API 交互

与 Kubernetes API 的任何交互都需要使用 OAuth 进行某种类型的身份验证。Pod 代表非人类用户，因此它需要服务帐户才能与 API 服务器交互。

默认情况下，Pod 会与一个服务帐户相关联，并且该服务帐户的凭据（令牌）会放置到此 Pod 中每个容器的文件系统中，路径为 /var/run/secrets/kubernetes.io/serviceaccount/token。关于这种模式是否可取仍存在争议，因此在 OpenShift 中这是可配置的，并且可以通过 ACS 等工具使用策略来实施。

与主机/Kubernetes 基础架构层交互

这种类型的交互不依赖于 Kubernetes API 调用。它实际上与底层主机的进程级权限管理（Linux 级权限）相关。

使用安全上下文约束（SCC）可映射 Pod 能够在底层基础架构上执行的操作（权限）以及它可以访问的资源。SCC 是一种 OpenShift 资源，用于限制 Pod 对某组资源的访问权限，类似于 Kubernetes 的安全上下文资源。

例如，进程可能具有也可能不具有在指定路径中创建文件的权限，或者可能不具有对现有文件的写入权限（它可能仅具有读取权限）。两者的主要目的都是限制 Pod 对主机环境的访问。您可以使用 SCC 来控制 Pod 权限，类似于使用基于角色的访问控制来管理用户特权。

与外部资源交互

有时，Pod 需要访问集群外部的资源。例如，它可能需要访问对象存储（如 S3 存储桶），以获取数据或日志文件。这就要求您了解资源如何对用户进行身份验证，以及您需在要与该资源通信的 Pod 中构建哪些内容。

Amazon 针对服务帐户角色（IRSA）的身份和访问权限管理（IAM）就是这种设计的一个典型示例，它为 Pod 提供一组凭据，用于访问 AWS 上的服务。创建 Pod 时，Webhook 会将变量（Kubernetes 服务帐户令牌的路径和所承担角色的 ARN）注入到引用服务帐户的 Pod 中。这一过程也被称为“mutating”（可变注入）。如果 IAM 代入的角色具有所需的 AWS 权限，则 Pod 可以使用临时 STS 凭据执行 AWS SDK 运维。

OpenShift 中容器化应用的身份验证和授权

最后一层是容器化应用。与上一层类似，每个容器都可以尝试访问以下内容：

• Kubernetes API
• 由集群内的其他容器或集群外部的资源提供的其他 API
• 非 API 连接，例如访问特定端口以实现数据库接入

如上图所示，访问 API 的容器可以：

• 使用与应用关联的身份验证凭据（例如，使用 Kubernetes 机密）直接访问另一个 API
• 使用端点支持的身份验证机制，直接访问非 API 端点
• 利用 Pod 服务帐户

直接调用 API

容器可以通过获取 KUBERNETES_SERVICE_HOST 和 KUBERNETES_SERVICE_PORT_HTTPS 环境变量来访问 Kubernetes API。对于非 Kubernetes API 流量，应用可以使用客户端库（如 AWS API）或开发人员创建的自定义集成。

基于非 API 的通信

应用可能需要连接到数据库，以检索或推送数据。在这种情况下，身份验证通常作为容器内代码的一部分进行处理，并且通常可以在运行时使用环境变量、机密和 ConfigMap 等进行更新。

使用服务帐户

建议的 Kubernetes API 服务器身份验证方法是使用服务帐户凭据。大多数编程语言都有一组支持的 Kubernetes 客户端库。基于这些库，Pod 的服务帐户凭据可用于与 API 服务器通信。OpenShift 会在每个 Pod 内自动挂载服务帐户，使其能够访问作用域令牌。

对于非 Kubernetes API 调用，容器在向外部 API 服务进行身份验证时也可以使用 Pod 服务帐户。

身份验证和授权

计算机需要知道用户是谁，以及该用户可以执行哪些操作。这就是身份验证和授权，现在您已经了解了 Kubernetes 和 OpenShift 是如何管理这些机制的。

感谢 Shane Boulden 和 Derek Waters 对本文的全面审阅和反馈。