В наше время у каждого есть несколько учетных записей и учетных данных, о которых нужно заботиться, поэтому каждому нужен достойный менеджер паролей, возможно, с открытым исходным кодом.
Когда дело доходит до управления паролями, в Linux есть много вариантов: например, в прошлом мы рассказывали о “pass”, отличном менеджере паролей, ориентированном на командную строку и основанном на стандартных инструментах, таких как GPG и git.
В этой статье мы рассмотрим альтернативу, которая может стать идеальным решением для частных лиц и небольших организаций: Vaultwarden.
Bitwarden или Vaultwarden
Bitwarden – это многофункциональный менеджер паролей с открытым исходным кодом, который поставляется со всеми функциями, которые сегодня ожидают от такого типа программного обеспечения, такими как 2-факторная аутентификация входа, поддержка случайной генерации надежных паролей, автозаполнение форм входа через специальные расширения браузера, клиентские приложения для мобильных устройств и многое другое.
🔑 Как установить и настроить Bitwarden
Хотя создание базового аккаунта Bitwarden является бесплатным, благодаря его открытому исходному коду можно самостоятельно разместить сервер Bitwarden, который в основном написан на C# и использует MS SQL в качестве базы данных.
Однако экземпляр Bitwarden может быть довольно требовательным к ресурсам и сложным в обслуживании.
По этим причинам была создана альтернативная, более легковесная реализация Bitwarden API: Vaultwarden.
Vaultwarden, ранее известный как Bitwarden_RS, написан на языке Rust и использует Sqlite в качестве базы данных.
Рекомендуемый способ развертывания экземпляра Vaultwarden – использовать официальный образ Docker; в этом руководстве мы узнаем, как это сделать, а также как получить сертификат Let’s encrypt TLS, используя Caddy в качестве службы обратного прокси.
Что такое Caddy?
Caddy – это веб-сервер с открытым исходным кодом, написанный на языке Go, который автоматически включает HTTPS для сайтов, которые он обслуживает.
Он может работать как обратный прокси-сервер и способен автоматически получать и обновлять сертификаты TLS с помощью протокола ACME (Automatic Certificate Management Environment).
Создание файла docker-compose
Поскольку нам нужно, чтобы наш микросервисный Vaultwarden работал вместе с Caddy, который сам по себе доступен как образ docker, для более простой оркестрации сервисов и взаимодействия контейнеров, мы хотим описать нашу маленькую инфраструктуру в файле docker-compose.
Вот как он должен выглядеть:
version: "3"
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: always
volumes:
- /etc/localtime:/etc/localtime:ro
- /srv/vaultwarden:/data
caddy:
image: caddy:2
container_name: caddy
restart: always
ports:
- 80:80
- 443:443
volumes:
- /srv/caddy/Caddyfile:/etc/caddy/Caddyfile:ro
- /srv/caddy/config:/config
- /srv/caddy/data:/data
- /srv/caddy/logs:/logs
environment:
DOMAIN: "<yourdomain>"
EMAIL: "<youremail>"
LOG_FILE: /srv/caddy/logs/access.log
Давайте разберем его.
Служба “vaultwarden”
Первый сервис, который мы определили в файле docker-compose, – это “vaultwarden”, он основан на образе vaultwarden/server.
В рамках определения сервиса мы указали, что хотим, чтобы полученный контейнер назывался “vaultwarden”, и, что очень важно, мы определили политику перезапуска, чтобы сервис всегда перезапускался, если он остановится.
Мы также определили два монтирования bind mounts для сопоставления определенных файлов на нашем сервере с другими файлами внутри контейнера.
Первый из этих файлов – /etc/localtime: мы сопоставили его с соответствующим файлом внутри контейнера, чтобы убедиться, что Vaultwarden использует тот же часовой пояс, что и хост.
С помощью второго bind-mount мы сопоставили каталог /data внутри контейнера с выбранным нами каталогом на хосте; в данном случае я выбрал /srv/vaultwarden/data, но путь может быть произвольным.
В каталоге “data”, помимо всего прочего, Vaultwarden хранит файл базы данных Sqlite, который мы обязательно хотим периодически резервировать (например, настроив специальное задание cron).
Служба “caddy”
Второй сервис, который мы определили в файле docker-compose, – это “caddy”.
Мы использовали официальный docker-образ Caddy, назвали контейнер “caddy” и, как и для службы “vaultwarden”, установили политику перезапуска “always”.
Чтобы использовать Caddy в качестве обратного прокси и позволить ему действовать в качестве клиента ACME для получения сертификата Let’s Encrypt, мы также сопоставили порты 80 и 443 на хосте с теми же портами внутри контейнера.
Затем мы определили четыре привязки: с помощью первой мы привязали /etc/caddy/CaddyFile внутри контейнера к произвольному пути в системе хоста (/srv/caddy/Caddyfile в данном случае).
Для тех, кто не знаком с Caddy, Caddyfiles – это удобные для человека конфигурации, используемые для определения одного или нескольких веб-сайтов (подробнее об этом чуть позже).
Второй, третий и четвертый bind-mounts, которые мы определили, привязывают каталоги /data, /config и /logs внутри контейнера к каталогам /srv/caddy/data, /srv/caddy/config и /srv/caddy/logs на хостовой системе, соответственно.
Наконец, мы определили некоторые переменные окружения, которые в дальнейшем будут использоваться в Caddyfile: DOMAIN – домен, который мы хотим использовать для Vaultwarden и для которого мы хотим получить сертификат, EMAIL – электронная почта, которую нужно связать с запросом, и LOG_FILE, которая используется для определения пути к файлу, куда должны записываться журналы Caddy.
Создание Caddyfile
Caddyfiles используются для определения веб-сайтов при использовании Caddy.
В данном случае наш Caddyfile должен выглядеть следующим образом:
{$DOMAIN}:443 {
log {
output file {$LOG_FILE} {
roll_size 10MB
roll_keep 10
}
}
tls {$EMAIL}
reverse_proxy /notifications/hub vaultwarden:3012
reverse_proxy vaultwarden:80 {
header_up X-Real-IP {remote_host}
}
}
Первое, что мы указываем в Caddyfile, – это адрес сайта.
В данном случае мы использовали нотацию {$DOMAIN}, которая будет заменена значением переменной окружения DOMAIN, которую мы определили в файле docker-compose для сервиса “caddy”.
Определение сайта записывается между фигурными скобками.
Настройка логов
Первое, что мы определили, это поведение логирования с помощью директивы log.
Используя output, мы указали, куда должны записываться журналы.
Caddy управляет сообщениями журнала с помощью “модулей”.
По умолчанию используется модуль “stderr”, который записывает логи на консоль (в дескриптор стандартного файла ошибок).
Поскольку в данном случае мы хотим, чтобы журналы записывались в файл, вместо этого мы указали Caddy использовать модуль “file”.
Наконец, вместо пути к файлу журнала мы использовали переменную окружения LOG_FILE, которую мы определили ранее.
Затем мы перешли к определению ротации журналов с помощью директив roll_size и roll_keep. Первая используется для определения размера файла, который должен быть “свернут” (в данном случае 10 МБ), а вторая – для определения количества файлов журнала.
Настройка обратного прокси
Следующее, что мы сделали, это настроили поведение обратного прокси для Caddy.
Мы сделали это с помощью директивы reverse_proxy.
Синтаксис для использования этой директивы следующий:
reverse_proxy [<matcher-token>][<upstreams...>]
Токен “matcher-token” используется для ограничения применения директивы.
В данном случае мы использовали путь, начинающийся со слэша: запрос будет обработан только при его совпадении.
Второй аргумент, используемый с директивой, – это бэкенд, на который должен быть перенаправлен запрос.
Мы перенаправляем запросы с путем /notifications/hub на “vaultwarden” на порт 3012 (в данном случае “vaultwarden” – это имя сервиса, которое мы определили в файле docker-compose и которое также используется как имя хоста для контейнера), а все остальное – на тот же бэкенд на порт 80.
Директива header_up используется для манипуляции заголовками: в данном случае мы устанавливаем “X-Real-IP” в значение “{remote_host}”, которое будет заменено на IP клиента.
Это делается для того, чтобы Vaultwarden мог использовать его в логах, а сервисы типа fail2ban могли его обрабатывать.
🛡️ CrowdSec, открытая, модернизированная и совместная система предотвращения вторжений (fail2ban)
В соответствии с тем, что мы определили в файле docker-compose, нам нужно сохранить содержимое в файл с именем “Caddyfile” (без расширения) в каталоге /srv/caddy, который должен быть создан заранее:
$ sudo mkdir /srv/caddy
Запуск служб
С созданным Caddyfile мы можем запустить контейнеры.
Для этого достаточно выполнить команду docker-compose up (в том же каталоге, где находится файл docker-compose, или передав путь к файлу docker-compose в качестве аргумента -f).
Поскольку мы хотим, чтобы службы работали в фоновом режиме, нам нужно использовать опцию -d:
$ sudo docker-compose up -d
Как мы уже говорили ранее, для того чтобы Caddy смог получить сертификат TLS через HTTP-запрос от Let’s encrypt, указанный нами домен должен быть общедоступным.
Если все идет как ожидалось, мы должны иметь возможность зайти на Vaultwarden по указанному адресу.
Теперь можно создать учетную запись и настроить зашифрованное хранилище.
Заключение
В этом руководстве мы узнали разницу между Bitwarden и Vaultwarden, а также увидели, как развернуть Vaultwarden на частном сервере с помощью Docker.
Мы также увидели, как использовать Caddy в качестве обратного прокси-сервера для получения TLS-сертификата от Let’s Encrypt.
