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

Question

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

为简化起见，假设应用程序是由 dotnet new 生成的简单 Hello World 控制台应用程序。 .这只是 2 个文件 程序.cs 和 项目.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 复制到 temp 文件夹中，为该特定应用程序构建一个新镜像，最后使用该镜像运行一个新容器。

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

编辑

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

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

Answer 1

据我所知，在 docker 中发生的事情仍然存在于 docker 中。

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

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

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

因此，我不认为使用 dockerfile 是一种矫枉过正，我会总结如下:

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