2. 保护对 Kubernetes 控制平面（API 服务器）的访问
Kubernetes 中的 API 访问控制是一个三步过程。 首先，对请求进行身份验证，然后检查请求的有效授权，然后执行请求准入控制，最后授予访问权限。 但在身份验证过程开始之前，确保正确配置网络访问控制和 TLS 连接应该是第一要务。
2.3 Kubernetes API访问认证最佳实践
使用外部身份验证
尽可能使用外部身份验证服务。例如，如果您的组织已经使用公司 IAM 服务管理用户帐户，则使用它来验证用户并使用 OIDC 等方法将他们连接到 Kubernetes（请参阅配置 OpenID Connect 指南）是最安全的身份验证配置之一。
每个用户一种身份验证方法
Kubernetes 短路了身份验证评估。这意味着，如果使用启用的身份验证方法之一对用户进行身份验证，Kubernetes 会立即停止进一步的身份验证并将请求作为经过身份验证的请求转发。由于 Kubernetes 允许同时配置和启用多个身份验证器，因此请确保单个用户帐户仅绑定到单个身份验证方法。
例如，在恶意用户配置为使用两种不同方法中的任何一种进行身份验证的情况下，如果该用户找到绕过弱身份验证方法的方法，则该用户可以完全绕过自第一个模块成功身份验证以来的更强身份验证方法请求短路评估。 Kubernetes API 服务器不保证身份验证器的运行顺序。
停用未使用的身份验证方法和未使用的令牌
对未使用的身份验证方法和身份验证令牌执行定期审查，并删除或禁用它们。管理员经常使用某些工具来帮助简化 Kubernetes 集群的设置，然后切换到其他方法来管理集群。在这种情况下，重要的是，如果不再使用以前使用的身份验证方法和令牌，则必须对其进行彻底审查和停用。
避免使用静态令牌
静态令牌无限期加载，直到服务器状态在线。因此，如果令牌被盗用，并且您需要轮换令牌，则需要完全重启服务器以清除被盗用的令牌。虽然使用静态令牌配置身份验证更容易，但最好避免使用这种身份验证方法。确保 kube-apiserver 未使用 --token-auth-file=STATIC_TOKEN_FILE 选项启动。
避免通过身份验证代理进行身份验证
Authenticating Proxy 告诉 Kubernetes API 服务器根据 HTTP 头中提到的用户名来识别用户，例如 X-Remote-User: [username]。 这种身份验证方法非常可怕，因为如果您知道 HTTP 在内部是如何工作的，那么客户端可以完全控制拦截和修改 HTTP 标头。
例如，以下传入请求指定经过身份验证的用户“dev1”：
GET / HTTP/1.1 X-Remote-User: dev1 X-Remote-Group: devgroup1 X-Remote-Extra-Scopes: profile
那么是什么阻止了恶意用户拦截或自定义请求和转发：
GET / HTTP/1.1 X-Remote-User: administrator X-Remote-Group: devgroup1 X-Remote-Extra-Scopes: profile
这种方法容易受到 HTTP 标头欺骗的影响，避免欺骗的唯一保护措施是基于 mTLS 的信任，其中 kube-apiserver 信任由受信任的 CA 签名的客户端证书。
如果您确实需要使用身份验证代理（不推荐），请确保充分考虑有关证书的安全问题。
禁用匿名访问
默认情况下，未经身份验证但未被拒绝的 HTTP 请求被视为匿名访问，并被标识为属于 system:unauthenticated 组的 system:anonymous 用户。除非有充分的理由允许匿名访问（默认启用），否则在启动 API 服务器时将其禁用为 kube-apiserver --anonymous-auth=false。
原文：https://goteleport.com/blog/kubernetes-api-access-security/