Могу ли я использовать секреты докеров в инфраструктуре AWS ECS?

Разве нет способа создать отдельный файл или что-то, что я мог бы использовать для каждой среды, независимо от того, работает ли это мой локальный с помощью docker run, CI или AWS ECS? Или у меня нет Интернета?

Таргетинг на N-среду с таким условием, как Нет Интернета - это то, что вряд ли можно передать сервису AWS для сохранения в секрете, например параметров хранилища и т. Д.

Я могу предложить использовать точечный env, который не зависит от среды, все, что вам нужно для обработки разная среда из разных источников, например

• Вытяните из s3 при запуске на стадии подготовки и производства на AWS
• Свяжите локальный .env при работе на машине разработчика для обработки условия Нет интернета
• Извлеките из s3 или сгенерируйте динамическое точечное окружение для CI

Итак, разберитесь с этим, каждая среда потребляет соответствующий файл Dot ENV, вы можете добавить логику в точку входа Docker.

#!/bin/sh

if [ "${NODE_ENV}" == "production" ];then
   # in production we are in aws and we can pull dot env file from s3
   aws s3 cp s3://mybucket/production/.env /app/.env
elif [ "${NODE_ENV}" == "staging" ];then
   # in staging we also assume that we are in aws and we can pull dot env file from s3
   aws s3 cp s3://mybucket/staging/.env /app/.env
elif [ "${NODE_ENV}" == "ci" ];then 
   # generate dynamic ENV or pull from s3
   aws s3 cp s3://mybucket/ci/.env
else 
   echo "running against local env, please dot env file like docker run -it $PWD/.env:/app/.env ..."
fi
echo "Startin node application"
exec node "$@

Включите шифрование на s3, плюс только производственная среда env сможет извлекать производственный файл env, более строгая политика приведет к более безопасному механизму.

Для локальной настройки вы можете попробовать

docker run -it -e NODE_ENV="local" --rm $PWD/.env:/app/.env myapp

Наиболее распространенный способ передачи конфигурации среды в приложение, работающее в контейнере Docker, - это использовать переменную среды, предложенную в качестве третьего фактора. двенадцатифакторных приложений.

При этом ваше приложение должно считывать всю конфигурацию, включая секреты, из переменных среды.

Если вы работаете локально и вне контейнера Docker, вы можете вручную установить эти переменные среды, запустить сценарий, который экспортирует их в вашу оболочку, или использовать _ 1_ стиль помощник для вашего языка, который автоматически загружает переменные среды из файла среды и предоставляет их как переменные среды вашему приложению, чтобы вы могли их получить. с process.env.FOO, os.environ["FOO"], ENV['HOSTNAME'] или каким-либо другим способом язык вашего приложения обращается к переменным среды.

При локальном запуске в контейнере Docker вы можете избежать упаковки вашего .env файла в образ и вместо этого просто вставьте переменные среды из файла среды, используя _ 6_ аргумент docker run или вместо этого просто вручную введите переменные среды вручную с помощью --env.

Когда к ним просто обращаются локально, вам просто нужно убедиться, что вы не храните никаких секретов в системе управления версиями, поэтому добавьте свой .env файл или его эквивалент к вашему .gitignore.

Когда дело доходит до работы в CI, вам необходимо, чтобы ваша система CI надежно хранила эти секретные переменные, а затем вводила их во время выполнения. Например, в Gitlab CI переменные можно создать в настройки CI / CD проекта, это затем сохраняются в зашифрованном виде в базе данных и затем прозрачно вводятся в виде обычного текста во время выполнения в контейнер в качестве переменных среды.

Для развертывания в ECS вы можете сохранить несекретную конфигурацию напрямую как переменные среды в определении задачи. Это оставляет переменные среды доступными для чтения любому, у кого есть доступ только для чтения к вашей учетной записи AWS, что, вероятно, не то, что вам нужно для секретов. Вместо этого вы можете создать их в хранилище параметров SSM или Менеджер секретов, а затем обратитесь к ним в _ 11_ параметр определения вашей задачи:

Документация AWS включает этот небольшой пример определение задачи, которое получает секреты от менеджера секретов:

{
  "requiresCompatibilities": [
    "EC2"
  ],
  "networkMode": "awsvpc",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "httpd",
      "memory": 128,
      "essential": true,
      "portMappings": [
        {
          "containerPort": 80,
          "protocol": "tcp"
        }
      ],
      "logConfiguration": {
        "logDriver": "splunk",
        "options": {
          "splunk-url": "https://sample.splunk.com:8080"
        },
        "secretOptions": [
          {
            "name": "splunk-token",
            "valueFrom": "arn:aws:secretsmanager:us-east-1:awsExampleAccountID:secret:awsExampleParameter"
          }
        ]
      },
      "secrets": [
        {
          "name": "DATABASE_PASSWORD",
          "valueFrom": "arn:aws:ssm:us-east-1:awsExampleAccountID:parameter/awsExampleParameter"
        }
      ]
    }
  ],
  "executionRoleArn": "arn:aws:iam::awsExampleAccountID:role/awsExampleRoleName"
}