Как использовать docker secrets в bash скриптах?

Question

[Фёдор Колов]

Есть best practice по использованию в bash скриптах секреты из докеров?

Видел в разных докерах использование префикса "_FILE" и другие подходы. Хотелось бы узнать, есть ли готовые либы или куски кода, которые можно использовать в платных проектах.

Comments

[Сергей Соколов]

при сборке или в контейнере?

[Сергей Тарасов]

Рекомендую присмотреться к ansible vault. Я на работе использовал - очень удобно, не требует никакого спец-софта или серверов, подходит для хранения зашифрованных данных в гите, что позволяет использовать это в команде

Answer 1

[Alexey Dmitriev]

Best practice - это Vault и другие хранилища секретов.
Минимум - swarm с его docker secrets

Comments

[Фёдор Колов]

Для использования Vault тоже нужны или либы, ставить программы в docker или использовать через curl секреты.

Answer 2

[ky0]

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

Comments

[Фёдор Колов]

Доставить секрет не проблема. Проблема, что есть много способов его прочитать. Хотелось бы выяснить, какой из них лучше.

[ky0]

Фёдор Колов, все примерно одинаково хороши. Если в логах и списке процессов не светится - уже, считайте, норм.

Дёшево и сердито - через переменную окружения.

Answer 3

[rPman]

Переменные окружения, прописанные прямо в dockerfile или docker-compose.yml
Смонтированный каталог хост машины
Специализированны сервер, их тьма как мелких так и крупных типа vault

Пример самописного, секреты выдаются приложению снаружи (в момент развертывания приложения и при их смене) и хранятся во временных файлах /tmp у самого приложения, для этого в инфраструктуре уже должны быть соответствующие средства контроля перезапуска приложений (например если это docker контейнеры) что бы повторно отправлять секреты и мониторить их, в идеале что бы эти команды (на перезапуск) сама система выдачи секретов и отправляла

Answer 4

[Saboteur]

Безопасность зависит сугубо от того, как у вас настроен кластер, у кого какие права.
Если права контролируются и людей не много, можете просто секреты юзать и мапить их в файлы/переменные.

Если людей много, есть сложности с тем как ограничить безопасность для разных неймпейсов, думайте про внешнее хранилище, откуда секреты будут доставаться через доверенные роли/whitelist нод..

Answer 5

[Hardoman]

Нет смысла защищать секреты внутри контейнеров, как уже было сказано, если есть доступ к контейнеру, их в любом случае раскроют.
Озаботьтесь тем, чтобы при сборке и деплое контейнера секреты не передавались в открытом виде (в зависимости от инструмента деплоя - разные методы защиты, например в ansible используйте ansible-vault, если docker-compose, используйте файлы, которые маунтят секрет, чтобы не писать в compose файле секрет в открытом виде) :

version: '3.8'
    secrets:
      db_password:
        file: ./secrets/db_password.txt # Путь к локальному файлу с секретами 
    services:
      database:
        image: postgres
        environment:
          POSTGRES_PASSWORD_FILE: /run/secrets/db_password
        secrets:
          - db_password

Секрет у вас будет маунтиться в /run/secrets/, но надо все равно использовать внешний файл с паролем.

В swarm чуть более удобно - пароль берётся из секрета, который создаётся заранее

docker swarm init
docker secret create <secret_name> <file_path>

или

echo "mysecretvalue" | docker secret create <secret_name> -

version: '3.8'
    secrets:
      db_password:
        external: true # Указывает, что секрет уже создан в swarm
    services:
      database:
        image: postgres
        environment:
          POSTGRES_PASSWORD_FILE: /run/secrets/db_password
        secrets:
          - db_password

Comments

[Фёдор Колов]

Дело не в защите секретов, а использование их внутри докера. В вашем примере postgres умеет работать с секретами и постфиксом _FILE. Другой докер не может использовать постфикс _FILE. Из коробки докер не преобразует из _FILE в нужные переменные.

[Hardoman]

Фёдор Колов, это заблуждение. Docker не должен автоматически раскрывать переменные c префиксом _FILE

Поддержка суффикса `_FILE` для чтения значений переменных окружения из файлов не является стандартной функциональностью Docker, а реализована на уровне отдельных образов/приложений с помощью entrypoint.sh скрипта, который пробегает по таким переменным и читает файлы.

Какие образы поддерживают `_FILE`?
Некоторые популярные официальные образы поддерживают чтение переменных через `_FILE`, включая:

1. Базы данных
- PostgreSQL (`postgres`) – `POSTGRES_PASSWORD_FILE`, `POSTGRES_USER_FILE`, и др.
- MySQL (`mysql`) – `MYSQL_ROOT_PASSWORD_FILE`, `MYSQL_PASSWORD_FILE`
- MariaDB (`mariadb`) – аналогично MySQL
- MongoDB (`mongo`) – `MONGO_INITDB_ROOT_PASSWORD_FILE`

2. Веб-серверы и прокси
- Nginx (не все версии, зависит от конфигурации)
- Traefik (поддерживает `_FILE` для многих параметров)

3. Инструменты и брокеры сообщений
- Redis (`redis`) – `REDIS_PASSWORD_FILE`
- RabbitMQ (`rabbitmq`) – `RABBITMQ_DEFAULT_PASS_FILE`
- Elasticsearch (`elasticsearch`) – `ELASTIC_PASSWORD_FILE`

4. Другие популярные образы
- WordPress (`wordpress`) – `WORDPRESS_DB_PASSWORD_FILE`
- Keycloak (`keycloak`) – `KEYCLOAK_PASSWORD_FILE`

Как проверить, поддерживает ли образ `_FILE`?
1. Документация образа – Обычно в официальной документации (Docker Hub, GitHub) указывается, можно ли использовать `_FILE`.
2. Исходный код entrypoint-скрипта – Многие образы обрабатывают `_FILE` в своих скриптах запуска (`docker-entrypoint.sh`).

Альтернативы, если образ не поддерживает `_FILE`
1. Использовать `env_file` в `docker-compose.yml`

services:
  app:
    image: some-image
    env_file: .env  # или secrets.env

2. Передать секрет через переменную

services:
  app:
    image: some-image
    environment:
      DB_PASSWORD: ${DB_PASSWORD}  # берётся из .env или Docker-секретов

3. Монтировать секрет и читать его вручную

services:
  app:
    image: some-image
    secrets:
      - db_password
    volumes:
      - /run/secrets/db_password:/etc/app/password.txt

[Vitsliputsli]

Hardoman,

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

А если установить пользователя в контейнере не root, а секрет лежит в директории root без доступа для чтения?