加固指南 - 身份验证机制

选择适当的身份验证机制是确保集群安全的重要方面。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 与身份提供者集成。但是，当将 OIDC 身份验证用于 Kubernetes 时，务必考虑以下加固措施。

• 安装在集群中以支持 OIDC 身份验证的软件应与一般工作负载隔离，因为它将以高权限运行。
• 一些 Kubernetes 托管服务对可使用的 OIDC 提供者有限制。
• 与 TokenRequest 令牌一样，OIDC 令牌应该具有较短的有效期，以减少受损令牌的影响。

Webhook 令牌身份验证

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

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

身份验证代理

将外部身份验证系统集成到 Kubernetes 的另一种选择是使用 身份验证代理。使用此机制，Kubernetes 预计从代理接收带有特定标头值设置的请求，这些标头值指示要用于授权目的的用户名和组成员资格。需要注意的是，使用此机制时需要考虑一些特定的因素。

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

其次，务必注意，能够修改请求标头的攻击者可能能够未经授权访问 Kubernetes 资源。因此，务必确保标头得到适当保护，并且不会被篡改。