我能否通过挂载目录向由sbt-native-packager构建的本地Docker容器提供AWS凭据

Question

我们有一些使用sbt-native-packager构建的docker镜像，需要与AWS服务交互。在AWS之外运行它们时，我们需要显式提供凭据。

我知道我们可以显式地传递包含AWS凭证的环境变量。这样做会使我们的凭证保密变得复杂。一种选择是通过命令行提供它们，通常将它们存储到我们的shell历史记录中(是的，我知道这可以通过在命令开头添加一个空格来避免，但这很容易忘记)，并将它们置于意外复制/粘贴共享的更高风险中。或者，我们可以通过env-file提供它们。但这使我们有可能将它们签入到版本控制中，或者无意中将它们推送到另一个服务器。

我们发现，理想的做法是将本地~/.aws/目录挂载到docker容器的运行用户的主目录中。然而，我们试图让它与sbt-native-packager映像一起工作，但没有成功。

sbt本地打包镜像的一个独特细节(与我们的其他镜像相比)是，它们是使用docker的入口点而不是CMD来启动应用程序的。我不知道这是否与问题有关。

那么问题来了:是否可以在启动时通过命令行参数挂载AWS credentials文件夹，为sbt-native-packager创建的docker容器提供AWS凭据？

Answer 1

我遇到的问题与权限有关。在我的机器上，.aws文件的访问权限非常有限，sbt-native-packager映像中的默认用户是daemon。当挂载到容器中时，该用户没有读取我的文件的权限。

我可以通过在docker run命令中添加以下标志来获得我想要的行为：-v ~/.aws/:/root/.aws/ --user=root

在运行以查看HOME环境变量(挂载/.aws/文件夹的位置)并尝试cat已挂载文件夹的内容时，通过使用--entrypoint=ash标志，我能够发现这一点。

现在，我只需要了解以这种方式运行docker容器会给自己带来哪些安全漏洞。

Answer 2

我不完全确定为什么挂载~/.aws会有问题--通常这可能与对该目录的读取权限以及主机系统和容器之间的不同UID有关。

也就是说，我可以建议几个变通方法：

1. 使用环境变量文件，而不是在命令行中显式指定它们。在docuer run中，您可以通过指定--env-file来完成此操作。对我来说，这听起来是最简单的方法。
2. 装载不同的凭据文件并提供AWS_CONFIG_FILE环境变量以指定其位置。