Как установить и настроить Passbolt на VPS

MAATRIX

Когда в команде больше двух-трёх человек, пароли в общей заметке или в личном менеджере одного сотрудника — это не решение, а бомба замедленного действия: уволился человек — переписывайте всё. Passbolt закрывает эту проблему как открытый и self-hosted менеджер паролей с ролями, группами и шифрованием на базе OpenPGP — каждая запись реально зашифрована персональным ключом того, кому она доступна, а не общим мастер-паролем на всех. Дальше — установка на чистый VPS с нуля: от Docker Compose до бэкапа.

Что такое Passbolt и когда он лучше Vaultwarden

Vaultwarden — это совместимая реализация Bitwarden API, она отлично подходит и одному человеку, и команде, если вам достаточно организаций и коллекций Bitwarden. Passbolt устроен иначе и рассчитан именно на командную работу с паролями инфраструктуры:

• каждый пользователь получает собственную пару GPG-ключей, и сервер физически не может расшифровать пароли без приватного ключа конкретного человека;
• права выдаются на уровне групп и отдельных ресурсов — можно дать доступ к паролям от продакшен-БД только двум DevOps-инженерам, а остальной команде — только к паролям от рабочих SaaS;
• есть журнал действий (кто и когда открывал/менял пароль), общие папки, теги, импорт/экспорт в KDBX и CSV;
• есть браузерное расширение (Chrome, Firefox, Edge) и мобильные приложения, десктопного клиента в классическом виде нет — работа идёт через веб-интерфейс и расширение.

Из ограничений: сравнивать с Vaultwarden против Bitwarden в лоб не совсем корректно — у Passbolt другая модель распространения. Бесплатная Community Edition (CE) не включает часть функций Pro-версии (например, продвинутый SSO, мобильный офлайн-режим отдельных модулей) — для команды из 5-30 человек CE обычно хватает с запасом, но перед миграцией стоит свериться с актуальным списком фич на официальном сайте, потому что состав редакций меняется.

Требования к серверу и подготовка

Passbolt CE официально распространяется как Docker-образ, и это самый предсказуемый способ его развернуть — руками через apt пакетов под все дистрибутивы нет. Достаточно скромного VPS:

Подготовьте систему и поставьте Docker с плагином Compose:

sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
newgrp docker

docker compose version

Заранее направьте DNS-запись A (и, если нужно, AAAA) вашего поддомена, например passbolt.example.com, на IP сервера — она понадобится на шаге с HTTPS.

Установка Passbolt через Docker Compose

Создайте рабочую директорию и файл docker-compose.yml:

mkdir -p ~/passbolt && cd ~/passbolt
mkdir -p gpg jwt ssl
nano docker-compose.yml

Базовая конфигурация из связки MariaDB + Passbolt CE:

services:
  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MYSQL_RANDOM_ROOT_PASSWORD: "true"
      MYSQL_DATABASE: passbolt
      MYSQL_USER: passbolt
      MYSQL_PASSWORD: "СЛОЖНЫЙ_ПАРОЛЬ_БД"
    volumes:
      - db_data:/var/lib/mysql

  passbolt:
    image: passbolt/passbolt:latest-ce
    restart: unless-stopped
    depends_on:
      - db
    environment:
      APP_FULL_BASE_URL: "https://passbolt.example.com"
      DATASOURCES_DEFAULT_HOST: "db"
      DATASOURCES_DEFAULT_USERNAME: "passbolt"
      DATASOURCES_DEFAULT_PASSWORD: "СЛОЖНЫЙ_ПАРОЛЬ_БД"
      DATASOURCES_DEFAULT_DATABASE: "passbolt"
      # ключ сервера создадим на первом запуске командой ниже
    volumes:
      - gpg_data:/etc/passbolt/gpg
      - jwt_data:/etc/passbolt/jwt
      - ./ssl:/etc/ssl/certs/passbolt
    ports:
      - "127.0.0.1:8080:80"
      - "127.0.0.1:8443:443"

volumes:
  db_data:
  gpg_data:
  jwt_data:

Порты Passbolt здесь намеренно смотрят только на 127.0.0.1 — наружу сервер отдаёт трафик через отдельный Nginx с настоящим сертификатом (следующий раздел), а не через самоподписанный TLS контейнера.

Поднимите стек и дождитесь, пока база инициализируется:

docker compose up -d
docker compose logs -f passbolt

Сгенерируйте серверный GPG-ключ и JWT-ключи — без них Passbolt не поднимется:

docker compose exec passbolt su -m -c "gpg --batch --gen-key" -s /bin/bash www-data <<'EOF'
%no-protection
Key-Type: RSA
Key-Length: 3072
Name-Real: Passbolt Server
Name-Email: passbolt@example.com
Expire-Date: 0
%commit
EOF

docker compose exec passbolt gpg --list-keys --homedir /var/www/passbolt/config/gpg
docker compose exec passbolt su -m -c "bin/cake passbolt install --force" -s /bin/bash www-data

Если сборка сборки образа предлагает собственный healthcheck-скрипт генерации ключей (/docker-entrypoint.sh с -ec-init), можно воспользоваться им напрямую — в официальном образе такой путь описан в переменных окружения PASSBOLT_GPG_SERVER_KEY_*. Проверьте актуальный README вашего тега образа перед продакшен-развёртыванием — детали переменных периодически меняются между релизами CE.

HTTPS: Nginx как reverse proxy и Let's Encrypt

Ставим Nginx на хост и Certbot, как описано в установке Let's Encrypt SSL на VPS:

sudo apt install -y nginx certbot python3-certbot-nginx

Конфиг /etc/nginx/sites-available/passbolt.conf:

server {
    listen 80;
    server_name passbolt.example.com;

    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 $scheme;
        client_max_body_size 10m;
    }
}

Активируйте сайт и выпустите сертификат — Certbot сам допишет блок listen 443 ssl и редирект с 80 на 443:

sudo ln -s /etc/nginx/sites-available/passbolt.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d passbolt.example.com

Важный нюанс: значение APP_FULL_BASE_URL в docker-compose.yml должно точно совпадать с адресом, по которому люди открывают панель, включая https:// — иначе браузерное расширение будет спорить с сервером о происхождении запроса (ошибки CORS/CSRF на форме входа — частый симптом рассинхрона именно здесь).

Первый администратор, GPG-ключи и вход через расширение

Passbolt не создаёт пользователей через веб-форму регистрации — первого администратора заводит CLI-командой внутри контейнера:

docker compose exec passbolt su -m -c \
  "bin/cake passbolt register_user -u admin@example.com -f Иван -l Петров -r admin" \
  -s /bin/bash www-data

Команда выведет одноразовую ссылку вида https://passbolt.example.com/setup/install/... — она действует ограниченное время. Дальше на стороне сотрудника:

1. Установить браузерное расширение Passbolt (Chrome/Firefox/Edge) из официального стора.
2. Перейти по одноразовой ссылке — расширение подхватит процесс настройки.
3. Сгенерировать личную пару GPG-ключей прямо в браузере (или импортировать существующую) и задать мастер-пароль расширения — это отдельный секрет, известный только пользователю, сервер его не видит.
4. Скачать и сохранить в безопасном месте резервную копию приватного ключа — без него восстановить доступ при потере пароля браузера невозможно, у администратора нет "master override" на чужие зашифрованные записи.

Это и есть суть модели Passbolt: сервер хранит только зашифрованные блобы, расшифровка происходит на клиенте приватным ключом конкретного человека. Плюс в честной приватности, минус — восстановление реально сложнее, чем в системах с одним общим мастер-ключом организации, так что процедуру бэкапа ключей нужно продумать заранее (раздел ниже).

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

Из панели администратора (Passbolt → Administration → Users) заводите остальных сотрудников той же командой register_user, только с ролью user вместо admin:

docker compose exec passbolt su -m -c \
  "bin/cake passbolt register_user -u devops@example.com -f Анна -l Смирнова -r user" \
  -s /bin/bash www-data

Дальше работа строится вокруг групп, а не индивидуальных прав на каждый ресурс по отдельности:

• создайте группы по функции, а не по отделу целиком — например infra-prod, infra-staging, marketing-saas;
• на каждый пароль/секрет назначайте права владения (owner), редактирования (can update) или только чтения (can read) — владелец группы решает, кто внутри неё что видит;
• общие папки (folders) удобны для структуры "клиент → проект → окружение" — это отдельная сущность, права на неё не всегда автоматически наследуются ресурсами внутри, это стоит проверить на своей версии перед тем как полагаться на структуру как на единственный барьер доступа;
• при увольнении сотрудника — не удаляйте учётку сразу, а сначала переназначьте владение его личными паролями на другого администратора через раздел Users, иначе записи, где он был единственным owner, повиснут без доступа для остальных.

Резервное копирование, обновления и защита сервера

Зашифрованное содержимое в базе бесполезно без GPG-ключей контейнера — бэкапить нужно оба тома вместе:

docker compose exec db sh -c \
  'mysqldump -u passbolt -p"СЛОЖНЫЙ_ПАРОЛЬ_БД" passbolt' > passbolt_db_$(date +%F).sql

docker run --rm -v passbolt_gpg_data:/data -v $(pwd):/backup alpine \
  tar czf /backup/passbolt_gpg_$(date +%F).tar.gz -C /data .

Для регулярного автоматического бэкапа удобно взять уже готовый подход из BorgBackup на VPS — он умеет дедупликацию и шифрование архива, что уместно, когда бэкап и так содержит секреты компании.

Обновление Passbolt — это обновление тега образа и повторный запуск миграций:

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

Перед мажорным обновлением обязательно снимайте свежий бэкап БД и тома GPG — откат схемы базы вручную заметно сложнее, чем откат контейнера. Со стороны сервера имеет смысл сразу закрыть лишнее: настроить firewall так, чтобы наружу смотрели только 22 (по возможности — с другого порта и по ключу), 80 и 443, и поставить fail2ban для защиты формы входа Nginx от перебора.

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