时间戳

首页 > 解决方案 > 为什么使用 `--vm-driver=none` 启动的 Minikube 集群容易受到 CSRF 的影响？

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

问题描述

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

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

为什么主机易受攻击？这样的攻击将如何进行？

标签： csrfminikube

解决方案

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

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

论据--vm-driver=none：

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

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

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

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

是一个用于在现有基础架构上引导最佳实践 Kubernetes 集群的工具包。

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

针对 Web 攻击强化主 API #10351

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

推荐阅读