在 AWS 上为 Docker 容器存储配置文件的最佳方式是什么? [英] What's the best way to store a config file for a Docker container on AWS?

问题描述

我有一个 node.js 应用程序，它有一个包含敏感数据的配置文件.我想通过 AWS ECS(集群)作为 docker 容器启动它.

I have a node.js app which has a config file with sensitive data. I want to launch it through AWS ECS (cluster) as a docker container.

存储敏感配置数据的最佳方式是什么?

What would be the best way to store the sensitive config data?

我目前正在通过 Docker 容器的任务定义中的环境变量发送它们，但必须有更好的方法来做到这一点.

I am currently sending them through the environmental variables in the Task Definition of the Docker container, but there has to be a better way to do that.

这种事情的最佳实践是什么?我应该使用 Docker Secrets 还是 Amazon Secrets Manager?

What is the best practice for something like this? Shall I use Docker secrets or Amazon secrets manager?

我知道这是一个很笼统的问题，但我找不到答案，所以也许有人有推荐?

I know it's a pretty general question, but I couldn't find an answer to that, so maybe somebody has a recommendation?

推荐答案

很好的问题.我同意 SSM Parameter Store 或 AWS Secrets Manager 是这项工作的推荐工具，但在我看来，如果您遵循基础设施即代码原则，它们就不那么有用了.

Great question. I agree that the SSM Parameter Store or AWS Secrets Manager are the recommended tools for this job, but they are just not that usable in my opinion if you follow the infrastructure as code principle.

因此，我将配置文件放在同一个 Git 存储库中的 Terraform 脚本旁边，并在运行时将实际敏感数据(密码、密钥等)从 SSM 参数存储注入特定的目标文件.

Therefore I keep my configuration files right next to the Terraform scripts in the same Git repository and inject the actual sensitive data (passwords, keys, whatever) during runtime from the SSM Parameter Store into the specific target files.

与使用 AWS 提供的解决方案相比，这有几个优点:

This has several advantages over using the AWS provided solution:

• 没有大小限制(SSM Parameter Store 在免费版本中将您限制为 4 KB).
• 非敏感配置受版本控制，具有随之而来的所有优势.
• 我可以轻松查看当前使用的配置并更新它们，而无需登录 AWS 控制台等.

基本思路如下:我们将没有敏感数据的配置文件存储在Terraform旁边的存储库中.秘密存储在 AWS 参数存储中.为了在运行时将数据放入我们的容器中，我们修改了入口点.我们当然可以只创建修改后的图像，但在我看来，这会产生很大的维护开销.使用入口点方法，我们可以继续使用普通图像.

The basic idea is as following: We store configuration files without sensitive data in the repository next to Terraform. Secrets are stored in AWS parameter store. To get the data into our containers at runtime, we modify the entrypoint. We could of course just create modified images, but that creates a big maintenance overhead in my opinion. Using the entrypoint approach, we can keep using vanilla images.

缺点是我必须创建自定义入口点脚本.这意味着我必须找到我感兴趣的镜像的 Dockerfile 并提取用于启动在镜像中运行的实际进程的命令.

The disadvantage is that I have to create custom entrypoint scripts. That means that I have to find the Dockerfile of the image I'm interested in and extract the commands used to start the actual process running in the image.

我有一个这样的 git 存储库:

I have a git repository like this:

├── files
│   └── promstack
│       ├── grafana
│       │   ├── default-datasources.yml
│       │   ├── grafana.ini
│       │   └── run.sh
│       ├── loki
│       │   └── run.sh
│       ├── nginx
│       │   ├── nginx.conf
│       │   └── run.sh
│       └── prometheus
│           ├── prometheus.yml
│           ├── rules-alerting.yml
│           ├── rules-recording.yml
│           └── run.sh
├── myscript.tf
└── variables.tf

run.sh 脚本代表入口点.这是一个示例 run.sh:

The run.sh scripts represent the entrypoints. Here is an exemplary run.sh:

#!/bin/sh

set -x

require () {
    if [ ! "$1" ]; then 
        echo "ERROR: var not found"
        exit 1 
    fi 
}

expand () {
    var_name="${1}"
    file="${2}"

    eval var="$$var_name"

    sed -i "s+${${var_name}}+${var}+g" ${file}
    sed -i "s+$${var_name}+${var}+g" ${file}
}

require ${GRAFANA_INI}
require ${DEFAULT_DATASOURCES_YML}
require ${DOMAIN}

echo ${GRAFANA_INI} | base64 -d > /etc/grafana/grafana.ini
chmod 666 /etc/grafana/grafana.ini

expand DOMAIN /etc/grafana/grafana.ini

echo ${DEFAULT_DATASOURCES_YML} | base64 -d > /etc/grafana/provisioning/datasources/default.yml
chmod 666 /etc/grafana/provisioning/datasources/default.yml

su -s "/bin/sh" -c "/run.sh" grafana

这里是 Terraform 脚本的一部分(准确地说是 ECS 容器任务定义):

Here a part from a Terraform script (ECS Container task definition to be exact):

{
  name: "grafana",
  image: "grafana/grafana:7.0.5",
  portMappings: [{
    containerPort : 3000,
    hostPort: 0,
    protocol: "tcp"
  }],
  user: "0",
  entryPoint: [ "/bin/sh", "-c", join(" ", [
    "export DEFAULT_DATASOURCES_YML=${base64encode(file("${path.module}/files/promstack/grafana/default-datasources.yml"))};",
    "export GRAFANA_INI=${base64encode(file("${path.module}/files/promstack/grafana/grafana.ini"))};",
    "echo '${base64encode(file("${path.module}/files/promstack/grafana/run.sh"))}' | base64 -d | sh;"
  ])],
  secrets: [
    {
      name: "DOMAIN",
      valueFrom: "<my ssm parameter>"
    }
  ]
},

这篇关于在 AWS 上为 Docker 容器存储配置文件的最佳方式是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！