为什么使用 `--vm-driver=none` 启动的 Minikube 集群容易受到 CSRF 的影响？答案

【问题标题】：Why are Minikube clusters launched with `--vm-driver=none` vulnerable to CSRF?为什么使用 `--vm-driver=none` 启动的 Minikube 集群容易受到 CSRF 的影响？
【发布时间】：2019-01-13 11:50:57
【问题描述】：

当使用 --vm-driver=none 选项启动 Minikube 实例时，会收到以下警告：

WARNING: IT IS RECOMMENDED NOT TO RUN THE NONE DRIVER ON PERSONAL WORKSTATIONS
    The 'none' driver will run an insecure kubernetes apiserver as root that may 
    leave the host vulnerable to CSRF attacks

为什么主机容易受到攻击？这样的攻击如何运作？

【问题讨论】：

标签： csrf minikube

【解决方案1】：

跨站请求伪造是一种攻击：

欺骗用户不小心使用他们的凭据来调用状态更改活动

论据--vm-driver=none：

此驱动程序可用于在主机上而不是在 VM 上运行 Kubernetes 集群组件。

关于 minikube 内部攻击的文档很少。基本上，当您使用 --vm-driver=none 时，kubectl 配置和凭据将是 root 拥有的，并且可以在主目录中使用。您需要移动它们并设置适当的权限。此外，攻击者可以轻松访问通常用于保护免受此类攻击的秘密令牌。如果您不移动组件并设置权限，那么在以 root 身份引入请求时，它们可能会成为使用 apiserver 作为混淆代理的潜在载体。

我认为最危险的部分是：--vm-driver=none 将整个过程暴露为 root。您的 kubeapi 以 root 身份运行。如果攻击者可以利用这一点，他将控制以 root 身份运行的内核内运行的进程 - 正如我们所知，这使攻击者成为系统的所有者，并且不仅可以成为 CSFR 攻击的网关。

另外值得一提的是，在 minikube 中，安全性不是优先考虑的问题，因为它主要是学习工具，如果您想要更注重安全性的东西，您可以考虑 kubeadm，即：

是一个用于引导最佳实践 Kubernetes 集群的工具包现有的基础设施。

以下是 Kubernetes 开发人员关于实施 CSRF 和执行此类攻击的一些历史对话，您可以在此处找到：

Harden master API against web attacks #10351

这是我能找到的，我建议你尝试在 GitHub 上询问开发人员，填写问题以获得更准确的信息。

【讨论】：

【解决方案2】：

你可以在这里找到答案：https://minikube.sigs.k8s.io/docs/reference/drivers/none/

安全性降低 minikube 启动可能在 Internet 上可用的服务。请确保您有防火墙来保护您的主机免受意外访问。例如： apiserver 监听 TCP *:8443 kubelet 监听 TCP *:10250 和 *:10255 kube-scheduler 监听 TCP *:10259 kube-controller 监听 TCP *:10257 容器可能对您的文件系统具有完全访问权限。通过使用 CVE-2019-5736 等容器逃逸漏洞，容器可能能够在您的主机上执行任意代码。请及时更新您的 minikube 版本。

【讨论】：