主从盐模式下的Kubernetes安全性

Question

我有几个关于Kubernetes主从盐模式的问题（从https://github.com/kubernetes/kubernetes/issues/21215重新发布）

• 您认为在GCE中拥有大型群集的任何人在暴露新漏洞时会对其进行升级吗？
• 如果没有GCE中的Master-minion盐设置，如何进行常规键旋转等操作？从长远来看，这不会让GCE集群变得更加脆弱吗？
• 我不是安全专家，所以这可能是一个天真的问题。由于GCE集群已经在一个相当紧密的网络中运行，因此主从之间的通信是一个主要问题吗？据我所知，在GKE中，主服务器被隐藏，访问权限仅限于GCP项目所有者。但在GCE中，主人是可见的。那么，这只是GCE设置的真正问题吗？

Answer 1

  

您认为在GCE中拥有大型群集的任何人在暴露新漏洞时会对其进行升级吗？

升级到新版本的k8s。如果存在内核或docker漏洞，我们将构建一个新的基本映像（container-vm），发送PR以在GCE中启用它，然后剪切引用新基本映像的新版本。如果存在k8s漏洞，我们会删除新版本的kubernetes，您可以使用github中的upgrade.sh脚本升级它。

  

如果没有GCE中的Master-minion盐设置，如何执行常规键旋转等操作？从长远来看，这不会让GCE集群变得更加脆弱吗？

通过更新主节点上的密钥，更新节点实例模板中的密钥，以及将节点从旧实例模板滚动到新实例模板。我们不想通过salt分发密钥，因为那时你必须弄清楚如何保护盐（这需要密钥然后也需要旋转）。相反，我们使用GCE元数据服务器在带外“分发”密钥。

  

由于GCE集群已经在一个相当紧密的网络中运行，主从之间的通信是一个主要问题吗？

对于GKE，主服务器在受保护网络之外运行，因此这是一个问题。 GCE遵循相同的安全模型（即使它不是绝对必要的），因为如果它们的配置方式有较少的偏差，它可以减轻维护两个系统的人员的负担。

  

那么，这只是GCE设置的真正问题吗？

对于大多数人来说，这可能不是一个问题。但您可以想象一家大公司在同一网络中运行多个集群（或其他工作负载），以便不同团队维护的服务可以轻松地通过内部云网络进行通信。在这种情况下，您仍然希望保护主服务器和节点之间的通信，以通过利用单个入口点进入网络来减少攻击者（或恶意内部人员）可能产生的影响。