在 docker 容器中运行不受信任的 .net 核心应用程序的最佳实践

Question

假设我想在 docker 容器中运行一些我不完全信任的第三方 .net 核心应用程序。

• 为简化起见，我们假设应用程序是由dotnet new 生成的简单Hello World 控制台应用程序。这只是 Program.cs 和 project.json 两个文件。

目前我尝试了以下方法：

• 将该应用程序复制到我主机的某个文件夹中

• 使用microsoft/dotnet 映像创建一个新容器，将该文件夹挂载为卷，运行特定命令来构建和运行应用程序：

  $ docker run --rm -it --name dotnet \
               -v /some/temp/folder/app:/app \
               microsoft/dotnet:latest \
               /bin/sh -c 'cd /app && dotnet restore && dotnet run'
  

我也在考虑使用 microsoft/dotnet 作为基础映像的预定义 dockerfile 的想法。它基本上会嵌入应用程序代码，将其设置为工作目录并运行恢复、构建和运行命令。

FROM microsoft/dotnet:latest
COPY . /app
WORKDIR /app

RUN ["dotnet", "restore"]
RUN ["dotnet", "build"]

ENTRYPOINT ["dotnet", "run"]

然后我可以将预定义的 dockerfile 复制到临时文件夹中，为该特定应用程序构建一个新映像，最后使用该映像运行一个新容器。

对于简单的命令行应用程序来说，dockerfile 方法是否矫枉过正？运行那些不受信任的应用程序的最佳做法是什么？（这可能是我完全忽略的）

编辑

由于我将在容器运行后丢弃容器，并且某些应用程序将生成 docker 命令，因此我可能会保留仅安装卷的第一个选项。

我还找到了this blog post，他们在其中构建了一个类似的 sanbox 环境并最终遵循相同的mounted volume approach

Answer 1

据我所知，在 docker 中发生的事情会留在 docker 中。

当您将卷 (-v) 链接到映像时，该过程可以更改您挂载的文件夹中的文件。但只有那里。该进程不能跟随任何符号链接或退出已安装的文件夹，因为出于明显的安全原因，它被禁止。

当你不链接任何东西并将应用​​程序代码复制到图像中时，它肯定是孤立的。

tcp/udp 端口​​说明以及内存/cpu 消耗取决于您，您甚至可以将进程与互联网隔离e.g. like that

---

因此，我不认为使用 dockerfile 是矫枉过正，我会这样总结：

当您想运行一次时，尝试并忘记它 - 如果您可以输入讨厌的命令，请使用命令行。如果您打算更多地使用它 - 创建一个 Dockerfile。考虑到个人喜好问题，我认为在这里声明“最佳实践”的空间不大。