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

Question

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

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

对于简单的命令行应用程序，dockerfile是否会出现过度杀伤？运行那些不受信任的应用程序的最佳做法是什么？（可能是我完全忽略的那个）

修改

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

我还发现this blog post他们在那里构建了一个类似的sanbox环境并最终关注了mounted volume approach

Answer 1

据我所知，在码头工程中会发生什么，留在码头工人。

将卷（-v）链接到图像时，该过程可以更改您挂载的文件夹中的文件。但只有那里。由于出于明显的安全原因，该进程无法遵循任何符号链接或步出已装入的文件夹。

当您没有链接任何内容并将应用程序代码复制到图像中时，它肯定是孤立的。

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

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

如果你想运行一次，试一试并忘掉它 - 如果你输入讨厌的命令就可以使用命令行。如果您打算更多地使用它 - 创建一个Dockerfile。我没有看到很多空间来宣布＆＃34;最佳实践＆＃34;在这里，考虑到个人偏好的问题。