Docker 容器对 Kubernetes 主节点的影响答案

【问题标题】：Impact of Docker Containers in Kubernetes Master NodeDocker 容器对 Kubernetes 主节点的影响
【发布时间】：2020-06-24 12:54:05
【问题描述】：

我目前正在使用基于 k8s 的 Hyperledger Fabric v1.4 部署。生成的链码容器基本上是由运行在对等 pod 和 k8s 中的容器创建的，因此不了解和控制链码容器。在这样一个 Docker 容器与 k8s 一起运行并且 k8s 不知道特定 docker 容器的情况下，Docker 容器是否有可能以某种方式获得对 k8s 主 API 的访问权限并获得对整个 k8s 的访问权限因此聚类？

我问这个问题的目的是弄清楚是否有一种方法可以使用 k8s 中任何 pod 外部的容器，通过未经授权访问 k8s 来对 k8s 集群造成任何不良影响。我谈到的链码容器是使用受信任的模板图像创建的，容器中唯一可能的恶意组件是用户提供的单个 golang、java 或 nodejs 脚本。所以我真正的问题是，“是否有可能使用这些用户脚本获得对 k8s 集群的未经授权的访问？”而且我主要关注像 Azure Kubernetes Service 这样的管理器 k8s 服务。

【问题讨论】：

标签： docker kubernetes hyperledger-fabric hyperledger hyperledger-chaincode

【解决方案1】：

你的问题完全改变了意思，所以我会尝试重写答案。

您必须记住，默认情况下运行代码的 pod 仅限于运行代码的 namespace。如果你没有给它任何更高的权限。代码也没有以 root 身份运行。

您可以阅读有关Pod Security Policies 和Configure a Security Context for a Pod or Container 的信息。

TLDR。只要你不给它任何特殊的特权或权利，它就应该为你的集群节省很多。

【讨论】：

非常感谢@Crou 的详细回答！！我一定会调查所有这些资源。不过只是跟进。我提出这个问题的目的是弄清楚是否有一种方法可以使用外部容器通过获得未经授权的访问来对 k8s 集群造成任何不良影响。我谈到的链码容器是由受信任的模板创建的，唯一的恶意组件是用户提供的一个 golang、java 或 nodejs 脚本。所以我真正的问题是，“是否有可能使用这些用户脚本获得对 k8s 集群的未经授权的访问？”
@HardikGourisaria，我已经重写了答案。希望这能提供更多细节。
我会看看@Crou。非常感谢您花时间回答我的问题。对于任何形式的误解，我们深表歉意。
事实并非如此。 Fabric 1.4 需要通过以特权模式运行您的 pod 来访问实际的 Docker 守护程序，该模式存在于命名空间之外。除了采取一般的安全预防措施（正确配置防火墙、验证链代码）之外，这是您可以采取的保护自己的措施。
Fabric 2.0 引入了外部构建器，它允许您将链代码管理与对等体完全分离，从而摆脱 docker 守护进程的要求。您可以在此处阅读有关新模型的信息：hyperledger-fabric.readthedocs.io/en/release-2.0/…