强化指南 - 认证机制
选择适当的身份验证机制是保护集群安全的关键方面。Kubernetes 提供了几种内置机制，每种机制都有其自身的优缺点，在选择最适合您集群的身份验证机制时应仔细考虑。
通常建议尽可能少地启用身份验证机制，以简化用户管理并防止用户保留对不再需要的集群的访问权限。
值得注意的是，Kubernetes 在集群内没有内置的用户数据库。相反，它从配置的身份验证系统中获取用户信息，并使用该信息做出授权决策。因此，要审计用户访问，您需要审查每个配置的身份验证源的凭据。
对于多个用户直接访问 Kubernetes API 的生产集群，建议使用 OIDC 等外部身份验证源。下面描述的内部身份验证机制（例如客户端证书和服务帐户令牌）不适用于此用例。
X.509 客户端证书身份验证
Kubernetes 利用 X.509 客户端证书身份验证用于系统组件，例如 kubelet 向 API 服务器进行身份验证。虽然此机制也可用于用户身份验证，但由于以下限制，它可能不适合生产使用：
- 客户端证书无法单独撤销。一旦被泄露，攻击者可以使用证书直到其过期。为了减轻此风险，建议为使用客户端证书创建的用户身份验证凭据配置较短的生命周期。
- 如果需要使证书失效，则必须重新生成证书颁发机构的密钥，这可能会给集群带来可用性风险。
- 集群中没有创建客户端证书的永久记录。因此，如果需要跟踪所有已颁发的证书，则必须记录它们。
- 用于客户端证书身份验证的私钥不能受密码保护。任何可以读取包含密钥的文件的人都将能够使用它。
- 使用客户端证书身份验证需要客户端与 API 服务器之间直接连接，而不能有任何中间 TLS 终止点，这会使网络架构复杂化。
- 组数据嵌入在客户端证书的
O值中，这意味着用户的组员资格在证书的生命周期内无法更改。
静态令牌文件
尽管 Kubernetes 允许您从位于控制平面节点磁盘上的静态令牌文件加载凭据，但由于以下几个原因，不建议将此方法用于生产服务器：
- 凭据以明文形式存储在控制平面节点磁盘上，这可能存在安全风险。
- 更改任何凭据都需要重新启动 API 服务器进程才能生效，这可能会影响可用性。
- 没有可用的机制允许用户轮换其凭据。要轮换凭据，集群管理员必须修改磁盘上的令牌并将其分发给用户。
- 没有可用的锁定机制来防止暴力攻击。
引导令牌
引导令牌用于将节点加入集群，由于以下几个原因，不建议将其用于用户身份验证：
- 它们具有不适合一般使用的硬编码组成员资格，使其不适用于身份验证目的。
- 手动生成引导令牌可能会导致弱令牌被攻击者猜到，这可能存在安全风险。
- 没有可用的锁定机制来防止暴力攻击，使得攻击者更容易猜测或破解令牌。
ServiceAccount secret 令牌
Service Account 密钥是允许集群中运行的工作负载向 API 服务器进行身份验证的一个选项。在 Kubernetes < 1.23 中，这些是默认选项，但它们正在被 TokenRequest API 令牌取代。虽然这些密钥可用于用户身份验证，但由于多种原因，它们通常不适合：
- 它们不能设置过期时间，并且在关联的服务帐户被删除之前将一直有效。
- 身份验证令牌对任何可以读取它们所在命名空间中的密钥的集群用户都可见。
- Service Accounts 不能添加到任意组，这使得在使用它们时 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 资源的未经授权的访问。因此，确保头部得到妥善保护且无法篡改至关重要。