加固指南 - 身份验证机制
选择合适的身份验证机制是保护集群的关键。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 资源的未授权访问权限。因此，务必确保正确保护标头并且不能被篡改。