在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机密还是Amazon机密管理器?

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参数存储或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参数存储将您限制为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屋！