Почему ARG в DOCKERFILE не рекомендуется для передачи секретов?

Ответ 1

Обновление в январе 2017 года:

Докер (рой) 1.13 имеет docker secret.

Однако, поскольку прокомментировал Стив Хоффман (bacoboy):

[...] Секретная команда помогает только пользователям роялить не более общее решение (например, с прикреплением постоянных томов).
Как вы управляете своими секретами (то, что они есть и кто имеет к ним доступ) очень зависит от системы и зависит от того, какие биты платного и/или OSS вы собираете вместе, чтобы создать свою "платформу".
С Docker компания переходит на предоставление платформы, я не удивлен, что их первая реализация - это рой, основанный так же, как Hashicorp интегрирует Vault в Atlas - это имеет смысл.

Действительно, как передаются секреты, выходит за пределы пространства docker run.
AWS делает такие вещи с ролями и политиками для предоставления разрешений на отказ/отказ и SDK.
Шеф-повар делает это с использованием зашифрованных баз данных и криптовальной "начальной загрузки" на auth.
У K8S есть своя версия того, что только что было выпущено в 1.13.
Я уверен, что mesos добавит подобную реализацию вовремя.

Эти реализации, похоже, попадают в 2 лагеря.

• передать секрет с помощью тома, которое предоставляет "платформа" или (секрет шеф-повара/докера/k8s
• передать учетные данные, чтобы поговорить с внешней службой, чтобы получить вещи при загрузке (iam/credstash/etc)

Оригинальный ответ: ноябрь 2015 г.

Это было введено в commit 54240f8 (docker 1.9, ноябрь 2015 г.), из PR 15182,

Среда сборки добавляется к командной строке промежуточного континента для помощи в поиске кеша.
Это также помогает отслеживать структуру. Но это также делает функцию менее безопасной с точки зрения передачи тайнов времени сборки.

проблема 13490 повторяет:

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

Как упоминалось в 9176 комментарии:

env - неправильный способ передачи секретов. Мы не должны пытаться изобретать колесо и предоставлять механизм защиты от несанкционированного доступа прямо из коробки.

Когда вы храните секретные ключи в среде, вы склонны случайно их подвергать - именно то, чего мы хотим избежать:

• Учитывая, что среда неявно доступна для процесса, невероятно сложно, если не невозможно, отслеживать доступ и как содержимое подвергается воздействию
• Это невероятно распространено, когда приложения захватывают всю среду и распечатывают ее, поскольку она может быть полезна для отладки или даже отправлять ее как часть отчета об ошибке. Так много секретов просочилось в PagerDuty, что у них есть хорошо смазанный внутренний процесс, чтобы очистить их от их инфраструктуры.
• Переменные среды передаются дочерним процессам, что позволяет непреднамеренный доступ и нарушает принцип наименьших привилегий. Представьте, что в рамках вашего приложения вы обращаетесь к стороннему инструменту, чтобы выполнить какое-либо действие, и вдруг сторонний инструмент имеет доступ к вашей среде, и бог знает, что он с ним сделает.
• Это очень часто встречается для приложений, которые приводят к сбою для хранения переменных среды в лог файлах для последующей отладки. Это означает секреты в текстовом формате на диске.
• Включение секретов в переменные env быстро превращается в племенные знания. Новые инженеры не знают, что они есть, и не знают, что они должны быть осторожны при обработке переменных окружения (их фильтрации в подпроцессы и т.д.).

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

Ответ 2

Простая причина в том, что значение секретности видимо для любого с изображением, просто запустив на нем history.

Возьмите этот файл докеры:

FROM alpine

ARG secret

RUN echo "${secret}"

(Ницца и просто, просто чтобы проиллюстрировать, как вы можете использовать секрет.)

то мы построим его $ docker build --build-arg secret=S3CR3T - < Dockerfile

Sending build context to Docker daemon 2.048 kB
Step 1 : FROM alpine
 ---> 13e1761bf172
Step 2 : ARG secret
 ---> Running in 695b7a931445
 ---> 5414c15a1cb6
Removing intermediate container 695b7a931445
Step 3 : RUN echo "${secret}"
 ---> Running in c90cf0d1414b
s3cr3t
 ---> f2bcff49ac09
Removing intermediate container c90cf0d1414b
Successfully built f2bcff49ac09

И пример того, как получить "секретный" обратно (посмотрите на |1 secret= в первой строке):

$ docker history f2bcff49ac09
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
f2bcff49ac09        8 seconds ago       |1 secret=S3CR3T /bin/sh -c echo "${secret}"    0 B
5414c15a1cb6        8 seconds ago       /bin/sh -c #(nop) ARG secret                    0 B
13e1761bf172        6 months ago        /bin/sh -c #(nop) ADD file:614a9122187935fccf   4.797 MB

Это тот случай, если вы создали изображение локально или вытащили его из реестра.

Если ваша цель состоит в том, чтобы сохранить секрет времени сборки из работающего контейнера, то использование ARG поможет вам - рассмотрите это:

$ docker run --rm -ti f2bcff49ac09 sh
/ # env
HOSTNAME=7bc772fd0f56
SHLVL=1
HOME=/root
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
$ # Note no secret in the above output

Ответ 3

Я думаю, что новая (17.05) докерная функция Multi-stage Builds (https://docs.docker.com/engine/userguide/eng-image/multistage-build/) смягчает эти (действительные) проблемы простое использование --build-Arg.

FROM mybuildertools
ADD my-git-creds /root/.ssh
RUN git clone [email protected]:example/foo /src
FROM mybuildertools
COPY --from=0 /src /src
RUN ...build /src with no git credentials ending up in final image...

К сожалению, кажется, что нет простого способа разрешить последующие перестройки (например, изменения на этапе сборки в файле Docker), если у вас нет каталога "my- git -creds".

Ответ 4

Я написал https://github.com/abourget/secrets-bridge для решения проблемы секретов времени сборки.

Он создает конфигурацию сбрасывания, которую вы можете передать как аргумент построения, во время процесса сборки он будет подключаться к хосту и извлекать секреты, использовать их, а затем вы можете убить мост узла. Даже если build-args где-то сохраняются, они становятся бесполезными в момент выхода сервера.

Сервер поддерживает пересылку агента SSH, туннелируется через интернет-связь TLS. Он также работает на Windows!

Надеюсь, что это поможет.