Passbolt в Docker Compose: готовый файл

MAATRIX

Vaultwarden хорош для личных паролей и небольшой команды, но у него нет ролей, групп и разграничения доступа по проектам — либо человек в организации, либо нет. Passbolt решает именно это: каждый пароль шифруется отдельным GPG-ключом, доступ выдаётся на конкретный ресурс конкретному человеку или группе, а администратор видит, кто и когда что открывал. Ниже — рабочий docker-compose.yml, который поднимает Passbolt CE с нуля за 15 минут, и что делать дальше, чтобы это не развалилось при первом обновлении.

Что такое Passbolt и чем он отличается от Vaultwarden

Passbolt — open-source менеджер паролей для команд, построенный вокруг OpenPGP. Ключевая архитектурная разница с Vaultwarden/Bitwarden:

• Шифрование на уровне пары ключей, а не мастер-пароля. У каждого пользователя есть собственная GPG-пара. Сервер хранит пароли, зашифрованные публичным ключом получателя, и физически не может их прочитать без приватного ключа пользователя.
• Доступ выдаётся точечно. Ресурс (пароль) можно расшарить на конкретного человека или группу с одним из трёх уровней прав — «только чтение», «редактирование», «владелец» (полный контроль, включая передачу прав).
• Есть общие папки (folders). Структура похожа на файловую систему: папка отдела, вложенная папка проекта, права наследуются или переопределяются точечно.
• Работа через браузерное расширение. Веб-интерфейс сам по себе не расшифровывает пароли — этим занимается расширение (Chrome/Firefox/Edge), которое держит приватный ключ на стороне клиента.

Passbolt CE (Community Edition, бесплатная) закрывает 90% потребностей команды до ~20-30 человек: роли admin/user, группы, папки, права на ресурс, MFA. Более гранулярный RBAC, SSO, доменные политики и часть отчётности — это уже Pro/Enterprise. Если вам достаточно единого хранилища на всю команду без разделения по ролям — присмотритесь к Vaultwarden на VPS, он проще в администрировании.

Требования к серверу

Passbolt — это связка nginx + PHP-FPM + MySQL/MariaDB внутри контейнера приложения плюс отдельный контейнер БД. Для команды до 30-50 человек с запасом хватает:

Доступ по паролям — то место, где экономить на инфраструктуре не стоит: сервер должен быть под вашим полным контролем, с бэкапами и без общих ресурсов с посторонними арендаторами. Если Docker ещё не установлен, разверните его с нуля по инструкции для Ubuntu 24.04 или Debian 12.

Готовый docker-compose.yml

Структура: сеть без внешнего доступа для БД, отдельные volume для данных БД, GPG-ключей сервера, JWT-ключей и загруженных изображений (аватары, логотипы). Порт наружу открыт только на loopback — снаружи трафик будет приходить через reverse-proxy.

services:
  db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MYSQL_RANDOM_ROOT_PASSWORD: "true"
      MYSQL_DATABASE: passbolt
      MYSQL_USER: passbolt
      MYSQL_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql
    networks:
      - passbolt_net

  passbolt:
    image: passbolt/passbolt:latest-ce
    restart: unless-stopped
    depends_on:
      - db
    command: ["/usr/bin/wait-for.sh", "-t", "0", "db:3306", "--", "/docker-entrypoint.sh"]
    environment:
      APP_FULL_BASE_URL: https://${DOMAIN}
      DATASOURCES_DEFAULT_HOST: db
      DATASOURCES_DEFAULT_USERNAME: passbolt
      DATASOURCES_DEFAULT_PASSWORD: ${DB_PASSWORD}
      DATASOURCES_DEFAULT_DATABASE: passbolt
      EMAIL_DEFAULT_FROM: ${SMTP_FROM}
      EMAIL_TRANSPORT_DEFAULT_HOST: ${SMTP_HOST}
      EMAIL_TRANSPORT_DEFAULT_PORT: ${SMTP_PORT}
      EMAIL_TRANSPORT_DEFAULT_USERNAME: ${SMTP_USER}
      EMAIL_TRANSPORT_DEFAULT_PASSWORD: ${SMTP_PASSWORD}
      EMAIL_TRANSPORT_DEFAULT_TLS: "true"
    volumes:
      - gpg_data:/etc/passbolt/gpg
      - jwt_data:/etc/passbolt/jwt
      - images_data:/usr/share/php/passbolt/webroot/img/public
    ports:
      - "127.0.0.1:8443:443"
      - "127.0.0.1:8080:80"
    networks:
      - passbolt_net

volumes:
  db_data:
  gpg_data:
  jwt_data:
  images_data:

networks:
  passbolt_net:
    internal: false

Оба порта (80 и 443) намеренно проброшены только на localhost: снаружи с ними будет работать reverse-proxy на хосте, а не сам контейнер напрямую. Так вы получаете нормальный Let's Encrypt сертификат вместо самоподписанного, который встроен в образ по умолчанию.

Переменные окружения и .env

Рядом с docker-compose.yml создайте .env:

DOMAIN=passbolt.example.com
DB_PASSWORD=сгенерируйте_длинный_случайный_пароль

SMTP_FROM=passbolt@example.com
SMTP_HOST=smtp.example.com
SMTP_PORT=587
SMTP_USER=passbolt@example.com
SMTP_PASSWORD=пароль_от_почтового_ящика

SMTP здесь не опция «для галочки» — через него уходят приглашения новых пользователей, ссылки восстановления доступа и уведомления о смене прав на ресурсы. Без рабочего SMTP новых людей в Passbolt добавить не получится: ссылка регистрации формируется в письме. Проще всего взять внешний SMTP-релей (Mailgun, Postmark, Yandex 360 для домена) — поднимать полноценный почтовый сервер только ради этого не имеет смысла.

Права на .env стоит сразу ограничить:

chmod 600 .env

Первый запуск, установка и создание администратора

Поднимаем стек:

docker compose up -d
docker compose logs -f passbolt

Дождитесь строки о готовности приложения (обычно контейнер сначала ждёт БД, потом накатывает миграции — на слабом диске это может занять минуту-другую). Дальше — установка и создание сервера GPG-ключей:

docker compose exec passbolt su -m -c "bin/cake passbolt install --no-admin" -s /bin/sh www-data

Команда сгенерирует пару GPG-ключей сервера (публичный/приватный) и сохранит их в volume gpg_data — это отдельный ключ, который шифрует служебные данные приложения, не путайте его с личными ключами пользователей. Дальше создаём первого администратора:

docker compose exec passbolt su -m -c \
  "bin/cake passbolt register_user -u admin@example.com -f Ivan -l Petrov -r admin" \
  -s /bin/sh www-data

В выводе появится ссылка вида https://passbolt.example.com/setup/install/.... Откройте её в браузере, где установлено расширение Passbolt (Chrome, Firefox или Edge) — оно проведёт через генерацию личной GPG-пары пользователя, попросит сохранить резервную копию приватного ключа и подтвердить пароль. Без расширения интерфейс не даст завершить настройку — это осознанное архитектурное решение, а не баг.

Если письма с приглашением новым сотрудникам не уходят, проверьте SMTP-переменные и логи:

docker compose exec passbolt su -m -c "bin/cake passbolt send_test_email -r admin@example.com" -s /bin/sh www-data

Роли, группы и права доступа

В Passbolt CE три уровня разграничения, и их стоит проектировать заранее, а не по ходу дела:

1. Роль на уровне платформы: admin или user. Администраторы управляют пользователями, группами и настройками инстанса; обычные пользователи — только своими ресурсами и тем, что им расшарено.
2. Группы: логическое объединение людей («Backend», «DevOps», «Финансы»). Ресурс можно расшарить сразу на группу — удобнее, чем добавлять каждого по отдельности, и снимает доступ у всех разом при исключении из группы.
3. Права на конкретный ресурс: Read / Update / Owner. Owner может передавать права дальше и удалять ресурс, Update — менять пароль и описание, Read — только видеть и копировать.

Практическая схема для команды из нескольких отделов:

Группа "devops-team"
  └─ Папка "Production servers"
       ├─ Пароль "root@web-01" — Owner: DevOps lead, Update: DevOps
       └─ Пароль "db-backup-key" — Read: DevOps, Owner: Тимлид

Группа "finance"
  └─ Папка "Billing accounts"
       └─ Пароль "hosting-billing" — Owner: Финансовый директор

Важный нюанс: удаление пользователя из группы не отзывает доступ к ресурсам, которые ему расшарили лично, а не через группу — это нужно чистить руками через фильтр «поделено с» в панели администратора. Если в компании высокая текучка или подрядчики с временным доступом, заведите привычку раз в месяц проверять список персональных шарингов.

HTTPS через reverse-proxy, бэкап и обновление

HTTPS. Поскольку порты контейнера смотрят только на localhost, ставим перед ним nginx или Traefik с автоматическим Let's Encrypt — подробный разбор обеих схем есть в статье про Let's Encrypt на VPS. Минимальный конфиг nginx как reverse-proxy к порту 8080 (без SSL на самом Passbolt, TLS терминируется снаружи):

server {
    listen 443 ssl;
    server_name passbolt.example.com;

    ssl_certificate     /etc/letsencrypt/live/passbolt.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/passbolt.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Бэкап. Самое критичное — volume gpg_data: там лежит приватный ключ сервера, без которого приложение не расшифрует служебные данные даже при восстановлении БД из бэкапа на новом сервере. Бэкапить нужно все три тома вместе и синхронно:

docker compose exec db sh -c 'exec mysqldump -u passbolt -p"$MYSQL_PASSWORD" passbolt' > passbolt_db_$(date +%F).sql
tar czf passbolt_gpg_$(date +%F).tar.gz -C /var/lib/docker/volumes/PROJECTNAME_gpg_data/_data .
tar czf passbolt_jwt_$(date +%F).tar.gz -C /var/lib/docker/volumes/PROJECTNAME_jwt_data/_data .

Замените PROJECTNAME на реальное имя проекта compose (docker compose ls покажет). Для регулярного автоматизированного бэкапа volume’ов удобнее не городить cron-скрипты руками, а посмотреть на резервное копирование Docker volume — тот же подход применим и здесь.

Обновление.

docker compose pull passbolt
docker compose up -d passbolt
docker compose exec passbolt su -m -c "bin/cake passbolt migrate" -s /bin/sh www-data

Перед мажорным обновлением (смена версии, не патч) обязательно снимите бэкап всех трёх томов и БД — миграции необратимы, откатиться можно только восстановлением из бэкапа.

Частые вопросы