【问题标题】:Building Docker images provided by untrusted users in a SaaS在 SaaS 中构建由不受信任的用户提供的 Docker 映像
【发布时间】:2021-01-09 21:24:07
【问题描述】:

我正在构建一个类似于持续交付服务的多租户 SaaS,我需要基于该服务用户提供的源代码和 Dockerfile 构建一个 Docker 映像(该用户不是组织的一部分,并且无论如何都不能被信任)。

例如:

  1. 该服务的用户连接他自己的 Git 存储库
  2. 我们的 SaaS 将源代码(Ruby、JavaScript 等)下载到服务器并生成 Docker 映像作为输出
  3. docker 镜像已部署

但是我对步骤 (2) 有严重的安全问题... 在服务器上是否有任何安全的方法可以在不受信任的 Dockerfile/代码上执行 docker build

是否有任何配置选项可以使 Docker 安全?

是否有任何不同于docker build 的工具允许在共享环境(即多租户SaaS 的服务器)中安全地构建OCI 映像?

是否有任何 SaaS 已经允许您代表您的 SaaS 构建第三方代码?

否则,每次我需要构建 Docker 映像时,我都应该启动并删除一个 VM(例如 DO droplet、EC2 等)……但这似乎更复杂。

你有什么建议吗?你知道 CircleCI 或 Travis 使用什么策略来构建/运行不受信任的代码吗?

【问题讨论】:

    标签: docker security saas continuous-delivery


    【解决方案1】:

    这对于任何类型的构建都是一个问题,不仅仅是 Docker 镜像,但显然它也适用于此。构建脚本(Dockerfile 或其他)几乎可以做任何事情,如果不受信任,我认为没有办法使其安全。

    因此,这些服务所做的正是您所描述的,它们在隔离的一次性环境中运行。这些有时被称为跑步者。我认为您唯一安全的选择是在专用的、干净的(如“刚刚启动”)VM 上运行它,然后将其拆除。即使这样,也要非常小心如何配置该 VM,允许哪些网络连接(例如到您的内部网络)等等,因为如上所述,构建脚本可能会完全控制 VM。 (完全控制可能有点夸大其词,因为您不需要以 root 身份运行它,但要考虑恶意用户突破隔离子环境(如 chroot 等)的风险 - 最好将其建模为完全控制)。

    要做到这一点并不简单。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-08-16
      • 1970-01-01
      • 2020-09-18
      • 1970-01-01
      • 2020-04-29
      • 2021-07-19
      相关资源
      最近更新 更多