С тех пор, как был задан этот вопрос, в Docker многое изменилось, так что вот попытка дать обновленный ответ.
Во-первых, особенно с учетными данными AWS для контейнеров, уже работающих внутри облака, использование ролей IAM, как предлагает Вор, является действительно хорошим вариантом. Если вы можете это сделать, добавьте к его ответу еще один плюс один и пропустите все остальное.
Когда вы начинаете запускать что-то вне облака или имеете секреты другого типа, я рекомендую не хранить секреты в двух ключевых местах :
Переменные среды: когда они определены в контейнере, каждый процесс внутри контейнера имеет к ним доступ, они видны через / proc, приложения могут выгружать свою среду в стандартный вывод, где она сохраняется в журналах, и, что наиболее важно, они появляются в чистый текст при осмотре контейнера.
В самом изображении: изображения часто помещаются в реестры, где у многих пользователей есть доступ по запросу, иногда без каких-либо учетных данных, необходимых для получения изображения. Даже если вы удалите секрет с одного уровня, образ можно разобрать с помощью обычных утилит Linux, таких как, tarи секрет можно будет найти на шаге, на котором он был впервые добавлен к образу.
Итак, какие еще есть варианты секретов в контейнерах Docker?
Вариант A: если вам нужен этот секрет только во время сборки вашего образа, вы не можете использовать секрет до начала сборки и у вас еще нет доступа к BuildKit, то многоступенчатая сборка - лучший из плохих вариантов. Вы должны добавить секрет на начальные этапы сборки, использовать его там, а затем скопировать результат этого этапа без секрета на этап выпуска и только отправить этот этап выпуска на серверы реестра. Этот секрет все еще находится в кеше изображений на сервере сборки, поэтому я предпочитаю использовать его только в крайнем случае.
Вариант B: Также во время сборки, если вы можете использовать BuildKit, выпущенный в 18.09, в настоящее время существуют экспериментальные функции, позволяющие вводить секреты в качестве монтирования тома для одной строки RUN. Это монтирование не записывается в слои образа, поэтому вы можете получить доступ к секрету во время сборки, не беспокоясь, что он будет отправлен на общедоступный сервер реестра. Полученный Dockerfile выглядит так:
# syntax = docker/dockerfile:experimental
FROM python:3
RUN pip install awscli
RUN --mount=type=secret,id=aws,target=/root/.aws/credentials aws s3 cp s3://... ...
И вы создаете его с помощью команды 18.09 или новее, например:
DOCKER_BUILDKIT=1 docker build -t your_image --secret id=aws,src=$HOME/.aws/credentials .
Вариант C:Во время выполнения на одном узле, без режима Swarm или другой оркестровки, вы можете подключить учетные данные как том только для чтения. Для доступа к этим учетным данным требуется тот же доступ, который у вас был бы за пределами докера к тому же файлу учетных данных, поэтому он не лучше и не хуже, чем сценарий без докера. Что наиболее важно, содержимое этого файла не должно быть видимым при проверке контейнера, просмотре журналов или отправке образа на сервер реестра, поскольку в каждом сценарии том находится за его пределами. Это требует, чтобы вы скопировали свои учетные данные на хост-докер отдельно от развертывания контейнера. (Обратите внимание, что любой, у кого есть возможность запускать контейнеры на этом хосте, может просматривать ваши учетные данные, поскольку доступ к API-интерфейсу докеров является корневым на хосте, а root может просматривать файлы любого пользователя. Если вы не доверяете пользователям с root на хосте ,
Для a docker runэто выглядит так:
docker run -v $HOME/.aws/credentials:/home/app/.aws/credentials:ro your_image
Или для файла создания у вас будет:
version: '3'
services:
app:
image: your_image
volumes:
- $HOME/.aws/credentials:/home/app/.aws/credentials:ro
Вариант D:Благодаря инструментам оркестрации, таким как Swarm Mode и Kubernetes, у нас теперь есть поддержка секретов, которая лучше, чем объем. В режиме Swarm файл зашифровывается в файловой системе диспетчера (хотя ключ дешифрования тоже часто присутствует, что позволяет перезапустить диспетчер без ввода ключа дешифрования администратором). Что еще более важно, секрет отправляется только тем воркерам, которым нужен секрет (запуск контейнера с этим секретом), он сохраняется только в памяти на воркере, а не на диске, и вводится как файл в контейнер с tmpfs крепление. Пользователи на хосте за пределами роя не могут монтировать этот секрет непосредственно в свой собственный контейнер, однако с открытым доступом к API-интерфейсу докеров они могут извлечь секрет из работающего контейнера на узле, так что снова ограничьте, кто имеет этот доступ к API. Из compose эта секретная инъекция выглядит так:
version: '3.7'
secrets:
aws_creds:
external: true
services:
app:
image: your_image
secrets:
- source: aws_creds
target: /home/user/.aws/credentials
uid: '1000'
gid: '1000'
mode: 0700
Вы включаете режим роя с помощью docker swarm initдля одного узла, а затем следуете инструкциям по добавлению дополнительных узлов. Вы можете создать секрет извне с помощью docker secret create aws_creds $HOME/.aws/credentials. И вы развертываете файл набора с расширением docker stack deploy -c docker-compose.yml stack_name.
Я часто редактирую свои секреты, используя скрипт из: https://github.com/sudo-bmitch/docker-config-update
Вариант E: существуют другие инструменты для управления секретами, и мне больше всего нравится Vault, потому что он дает возможность создавать ограниченные по времени секреты, срок действия которых истекает автоматически. Затем каждое приложение получает свой собственный набор токенов для запроса секретов, и эти токены дают им возможность запрашивать эти ограниченные по времени секреты, пока они могут достичь сервера хранилища. Это снижает риск, если секрет когда-либо будет извлечен из вашей сети, поскольку он либо не будет работать, либо скоро истечет. Функциональные возможности AWS для Vault задокументированы по адресу https://www.vaultproject.io/docs/secrets/aws/index.html.