security - 客户端身份验证对于 k8s 来说足够好吗？

Question

我正在尝试保护我的 k8s 集群，并且正在研究 k8s 的客户端身份验证授权支持。我的要求是我希望能够向 k8s apiserver 唯一地标识自己(例如客户端)，但到目前为止我读到的有关客户端身份验证的所有内容都不是解决方案。

我的理解是服务器只会确保提供的客户端证书实际上是由证书颁发机构签名的。如果黑客获得由同一证书颁发机构签署的另一个证书(这在我的组织中并不难做到)并使用它与我的服务器通信，该怎么办？看起来像 Swarm 和 k8s 这样的流行编排都支持这个选项，并宣称它是最安全的，所以这样做肯定是有原因的。有人可以透露一些信息吗？

Answer 1

不仅验证证书是否经过CA授权。客户端证书还包含 Common Name (CN)可以与简单的 ABAC Authorization 一起使用限制特定用户或组的访问。

此外，获得签名证书应该并不容易。 IMO 对根 CA 的访问应该非常有限，并且应该可以理解谁被允许签署证书以及何时发生。理想情况下，根 CA 应该存在于离线主机上。

除此之外，听起来 CA 还用于其他目的。如果是这样，您可以考虑为客户端身份验证创建单独的根证书。您可以通过为 apiserver 上的 --client-ca-file 和 --tls-ca-file 设置不同的 CA 文件来为服务器证书使用不同的 CA。 。这样，您可以限制谁能够创建客户端证书，并仍然使用组织的 CA 验证服务器身份(可能已分发到所有组织计算机上)。

其他身份验证方法

如上所述，Kubernetes 还有一些其他身份验证方法。 static token file和 static password file缺点是 secret 必须以纯文本形式存储在磁盘上。此外，每次更改时都必须重新启动 apiserver。

Service account tokens指定供集群中运行的应用程序使用。

OpenID可能是客户端证书的安全替代方案，但据我所知，设置起来要困难得多。尤其是在还没有 OpenID 服务器的情况下。

我对其他身份验证方法了解不多，但它们看起来旨在与现有的单点登录服务集成。