强化指南 - 身份验证机制

有关 Kubernetes 中的身份验证选项及其安全属性的信息。

选择适当的身份验证机制是保护集群安全的关键方面。Kubernetes 提供了几种内置机制，每种机制都有其自身的优缺点，在为集群选择最佳身份验证机制时应仔细考虑。

通常，建议启用尽可能少的身份验证机制，以简化用户管理并防止用户保留对不再需要的集群的访问权限。

重要的是要注意，Kubernetes 在集群中没有内置的用户数据库。相反，它从配置的身份验证系统获取用户信息，并使用该信息做出授权决策。因此，要审核用户访问权限，您需要查看来自每个已配置身份验证源的凭据。

对于多个用户直接访问 Kubernetes API 的生产集群，建议使用外部身份验证源，例如 OIDC。下面描述的内部身份验证机制（例如客户端证书和服务帐户令牌）不适合此用例。

X.509 客户端证书身份验证

Kubernetes 利用 X.509 客户端证书 身份验证来验证系统组件，例如当 Kubelet 向 API 服务器验证身份时。虽然此机制也可用于用户身份验证，但由于以下几个限制，它可能不适合生产环境使用

  • 客户端证书不能单独吊销。一旦泄露，攻击者可以使用证书，直到证书过期。为了降低这种风险，建议为使用客户端证书创建的用户身份验证凭据配置较短的生存期。
  • 如果需要使证书无效，则必须重新生成证书颁发机构的密钥，这可能会给集群带来可用性风险。
  • 集群中没有创建的客户端证书的永久记录。因此，如果您需要跟踪所有颁发的证书，则必须记录它们。
  • 用于客户端证书身份验证的私钥不能使用密码保护。任何可以读取包含密钥的文件的人都可以使用它。
  • 使用客户端证书身份验证需要从客户端到 API 服务器的直接连接，中间没有任何 TLS 终止点，这可能会使网络架构复杂化。
  • 组数据嵌入在客户端证书的 O 值中，这意味着在证书的生存期内无法更改用户的组成员身份。

静态令牌文件

尽管 Kubernetes 允许您从位于控制平面节点磁盘上的 静态令牌文件 加载凭据，但不建议将此方法用于生产服务器，原因如下

  • 凭据以明文形式存储在控制平面节点磁盘上，这可能存在安全风险。
  • 更改任何凭据都需要重新启动 API 服务器进程才能生效，这可能会影响可用性。
  • 没有可用的机制允许用户轮换其凭据。要轮换凭据，集群管理员必须修改磁盘上的令牌并将其分发给用户。
  • 没有可用的锁定机制来防止暴力破解攻击。

引导令牌

引导令牌 用于将节点加入集群，不建议将其用于用户身份验证，原因如下

  • 它们具有硬编码的组成员身份，不适合一般用途，因此不适合用于身份验证。
  • 手动生成引导令牌可能会导致生成弱令牌，攻击者可以猜到，这可能存在安全风险。
  • 没有可用的锁定机制来防止暴力破解攻击，这使得攻击者更容易猜测或破解令牌。

ServiceAccount 密钥令牌

服务帐户密钥 可作为一种选项，允许在集群中运行的工作负载向 API 服务器进行身份验证。在 Kubernetes < 1.23 中，这些是默认选项，但是，它们正在被 TokenRequest API 令牌取代。虽然这些密钥可用于用户身份验证，但由于以下几个原因，它们通常不适合

  • 它们不能设置过期时间，并且在关联的服务帐户被删除之前一直有效。
  • 任何可以读取定义它们的命名空间中的密钥的集群用户都可以看到身份验证令牌。
  • 服务帐户不能添加到任意组中，这使得在使用它们的情况下 RBAC 管理变得复杂。

TokenRequest API 令牌

TokenRequest API 是一个有用的工具，可用于生成用于服务身份验证到 API 服务器或第三方系统的短期凭据。但是，通常不建议将其用于用户身份验证，因为没有可用的吊销方法，并且以安全的方式将凭据分发给用户可能具有挑战性。

当使用 TokenRequest 令牌进行服务身份验证时，建议实施较短的生存期，以减少令牌泄露的影响。

OpenID Connect 令牌身份验证

Kubernetes 支持使用 OpenID Connect (OIDC) 将外部身份验证服务与 Kubernetes API 集成。可以使用各种软件将 Kubernetes 与身份提供程序集成。但是，在 Kubernetes 中使用 OIDC 身份验证时，请务必考虑以下强化措施

  • 应将集群中安装的用于支持 OIDC 身份验证的软件与一般工作负载隔离，因为它将以高权限运行。
  • 某些 Kubernetes 托管服务在可使用的 OIDC 提供程序方面受到限制。
  • 与 TokenRequest 令牌一样，OIDC 令牌的生存期应较短，以减少令牌泄露的影响。

Webhook 令牌身份验证

Webhook 令牌身份验证 是将外部身份验证提供程序集成到 Kubernetes 中的另一种选择。此机制允许通过 webhook 联系在集群内部或外部运行的身份验证服务，以做出身份验证决定。重要的是要注意，此机制的适用性可能取决于用于身份验证服务的软件，并且需要考虑一些特定于 Kubernetes 的因素。

要配置 Webhook 身份验证，需要访问控制平面服务器文件系统。这意味着，除非提供程序明确提供，否则使用托管 Kubernetes 将无法实现。此外，应将集群中安装的用于支持此访问的任何软件与一般工作负载隔离，因为它将以高权限运行。

身份验证代理

将外部身份验证系统集成到 Kubernetes 中的另一种选择是使用 身份验证代理。使用此机制时，Kubernetes 希望从代理接收设置了特定标头值的请求，指示要为授权目的分配的用户名和组成员身份。重要的是要注意，使用此机制时需要考虑一些特定因素。

首先，必须在代理和 Kubernetes API 服务器之间使用安全配置的 TLS，以降低流量拦截或嗅探攻击的风险。这可确保代理和 Kubernetes API 服务器之间的通信安全。

其次，重要的是要注意，能够修改请求标头的攻击者可能会获得对 Kubernetes 资源的未授权访问权限。因此，必须确保标头得到妥当保护，并且不会被篡改。

上次修改时间：2023 年 12 月 29 日下午 9:47 PST：修复过时的链接/锚 (bcc55ae7c9)