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