通过9个简单的步骤保护您的Kubernetes网络

为集群内的安全通信配置Kubernetes安全性可能非常令人困惑。朱莉娅·埃文斯(Julia Evans)在她的博客中写道：

各种Kubernetes组件都有大量不同的位置，您可以在其中放置证书/证书颁发机构。当我们设置集群时，我感觉证书、密钥和证书颁发机构有大约100亿个不同的命令行参数，我不明白它们是如何组合在一起的。

Kube API服务器-负责群集的整体功能并与用户交互。这基本上是您群集的控制中心。

其中API服务、kubelet和etcd是最关键的组件。假设Pod需要证书，它将与kubelet通信，然后kubelet将与API服务器通信以访问存储在etcd中的证书。

与主服务器的所有通信都通过API服务器进行。同样，与Worker节点的所有通信都通过kubelet进行。etcd保存集群的所有重要信息。因此，任何与etcd通信的东西都应该得到很好的保护。

API服务器与kubelet通信以获取日志，从用户接收配置，并与kubelet通信以使其成为现实。

默认情况下，从API服务器到kubelet的通信是通过未经验证的TLS进行的。这使得在不受信任的网络上运行群集是不安全的，因为这种通信容易受到中间人(或女人)的攻击。如果您在您的私有网络上运行，这种行为应该是可以接受的。但是，如果您愿意，可以使用“kubelet-Certificate-Authority”标志来验证kubelet的服务器证书。注SSH隧道已弃用，因此不再是推荐的解决方案。

在一些情况下会发生这种情况，例如当一个新节点联机，并且该节点需要一个新证书来与API服务器通信时。API服务器有一个Kubernetes API，它可以让您获得由您可以控制的CA签名的TLS证书。

请求使用相互TLS和API服务器在端口443上侦听。因此，默认情况下，主服务器可以在不受信任的网络上运行。

这里需要注意的另一件事是，您需要为kubelet证书设置证书轮换。默认情况下，它们的有效期为1年。

此通信的身份验证方法取决于您的需要。有几个选项，例如：

如果特定节点或Pod向kubelet请求证书，kubelet向API服务器发出请求，然后API服务器从etcd获取证书，则可能会发生这种情况。

与etcd的通信通过端口80上的本地主机进行，并且未经过身份验证或加密。您应该为通信的这一部分设置TLS，以便通过指定标志“etcd-certfile”向etcd服务器验证etcd实例的身份。

etcd的实例已经通过相互TL进行通信，因此集群的这一部分在不受信任的网络上运行也应该是安全的。

如您所知，不同节点或相同节点中的Pod之间无需NAT的无缝通信是Kubernetes组网的基本原则之一。所以这是另一条重要的沟通途径。

目前，此通信未加密且未进行身份验证。有一些方法可以使其更安全，例如使用一些网络策略提供商，如Tigera的Calico或Cilium来保护服务到服务的流量。至少，强烈建议根据您的应用程序使用某些网络策略提供程序。

您还可以使用像Istio这样的服务网格来对服务之间的流量实施相互TLS。仅使用整个服务网格来实施服务到服务通信之间的相互TLS似乎是一个巨大的要求，因此可以使用提供相同服务的网络策略提供程序，而不需要在每个Pod前面使用代理。

这里推荐的一件显而易见的事情是Pod安全策略。将在另一篇博客文章中详细说明这一点。

这条沟通路径非常关键，可能需要一个完整的帖子。

这种类型的通信是通过纯HTTP完成的，但实际上这种类型的通信甚至不应该直接发生。

用于保护从Kube控制器管理器到API服务器的通信。默认情况下，它使用端口10259并使用HTTPS身份验证。您还可以设置该选项和许多其他选项：

从Kubernetes1.13开始，安全端口10259可以用于Kube-Scheduler到api服务器的安全连接。

如果您希望确保节点到节点的通信也使用证书，则可以使用相同的证书签名API。

如果您发现上述内容有任何错误，将乐意改正，或者如果您有任何反馈，希望听到更多信息！