З моменту того, як було задано це питання, у Docker багато що змінилося, тож ось спробу оновленої відповіді.
По-перше, зокрема, з обліковими даними AWS для контейнерів, які вже запущені всередині хмари, використання ролей IAM, як вважає Вор, є дійсно хорошим варіантом. Якщо ви можете це зробити, додайте ще один плюс один до його відповіді і пропустіть решту цього.
Як тільки ви починаєте запускати речі поза хмарою або використовуєте інший тип секрету, є два ключових місця, які я рекомендую не зберігати:
Змінні середовища: коли вони визначені в контейнері, кожен процес всередині контейнера має до них доступ, вони видно через / proc, програми можуть скидати своє середовище в stdout, де воно зберігається в журналах, і найголовніше, що вони відображаються в чіткий текст при огляді контейнера.
В самому зображенні: зображення часто надсилаються до реєстрів, де багато користувачів мають доступ для витягування, іноді без будь-яких облікових даних, необхідних для витягування зображення. Навіть якщо ви видалите секрет з одного шару, зображення можна розібрати за допомогою звичайних утиліт Linux, наприклад, tarі секрет можна знайти з кроку, де він був вперше доданий до зображення.
То які ще є варіанти секретів у контейнерах Docker?
Варіант A: Якщо вам потрібен цей секрет лише під час збірки вашого зображення, ви не можете використовувати секрет до початку збірки і ще не маєте доступу до BuildKit, то багатоступенева збірка - найкращий з поганих варіантів. Ви повинні додати секрет до початкових етапів збірки, використовувати його там, а потім скопіювати висновок цього етапу без секрету до етапу випуску і лише просунути цей етап випуску на сервери реєстру. Цей секрет все ще знаходиться в кеші зображень на сервері збірки, тому я, як правило, використовую це лише в крайньому випадку.
Варіант B: Також під час побудови, якщо ви можете використовувати BuildKit, який був випущений в 18.09, на даний момент існують експериментальні функції, які дозволяють вводити секрети як об'ємне кріплення для однієї лінії RUN. Це монтування не записується на шари зображення, тому ви можете отримати доступ до секрету під час побудови, не турбуючись, що він буде перенесений на загальнодоступний сервер реєстру. Отриманий файл Docker виглядає так:
# 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:Під час виконання на одному вузлі, без режиму зграї чи іншої оркестрації, ви можете змонтувати облікові дані як том, призначений лише для читання. Доступ до цих облікових даних вимагає того самого доступу, який ви мали б за межами докера до того самого файлу облікових даних, тому він не кращий і не гірший за сценарій без докера. Найголовніше, що вміст цього файлу не повинен бути видимим під час перевірки контейнера, перегляду журналів або надсилання зображення на сервер реєстру, оскільки обсяг не відповідає такому в кожному сценарії. Для цього потрібно скопіювати свої облікові дані на хост докера, окремо від розгортання контейнера. (Зверніть увагу, будь-хто, хто має можливість запускати контейнери на цьому хості, може переглядати ваші облікові дані, оскільки доступ до API докера є root на хості, а root може переглядати файли будь-якого користувача. Якщо ви не довіряєте користувачам root на хості ,
Для 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, ми тепер маємо підтримку секретів, яка краща за обсяг. У режимі зграї файл шифрується у файловій системі менеджера (хоча там часто є і ключ розшифровки, що дозволяє перезапустити менеджер без введення адміністратором ключа розшифровки). Що ще важливіше, секрет надсилається лише працівникам, яким потрібен секрет (запуск контейнера з цим секретом), він зберігається лише в пам’яті на робочому місці, ніколи не на диску, і вводиться як файл у контейнер за допомогою tmpfs кріплення. Користувачі на хості поза роєм не можуть монтувати цей секрет безпосередньо у свій власний контейнер, однак, маючи відкритий доступ до API докера, вони можуть витягти секрет із запущеного контейнера на вузлі, тому знову обмежте, хто має цей доступ до API. З композиції ця секретна ін’єкція виглядає так:
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: Існують інші інструменти для управління секретами, і мій улюблений - Сейф, оскільки він дає можливість створювати обмежені в часі секрети, які автоматично закінчуються. Потім кожна програма отримує власний набір токенів для запиту секретів, і ці маркери дають їм можливість запитувати ці обмежені в часі секрети до тих пір, поки вони можуть дістатися до сервера сховища. Це зменшує ризик, якщо секрет коли-небудь буде вилучено з вашої мережі, оскільки він або не буде працювати, або швидко закінчиться. Функціональність, специфічна для AWS для Сейфу, задокументована за адресою https://www.vaultproject.io/docs/secrets/aws/index.html