
Комментарии 16
Сам активно гоняю VW, но для личного/семейного пользования. От корпоративного отказались из-за скудной поддержки разных корп фич, в частности, LDAP'а. Остановились на платных аналогах. Контора не обеднеет, а вот качество жизни улучшается заметно.
Главный минус держать волт за впн - это если упадет сам впн, а тебя рядом нет. Поэтому личный держу открытым, проблему особо любопытных пока удается сдержать настроенным fail2ban
Согласен.
1) У клиента есть отдельно сис админ, который чисто сетевухой занимается и самим ВПН. Поэтому это, так скажем, его обязанность и таких случаев ещё не было.
Но на раскате проблема с availability другая: так как машина под вольт - это ранее обычный стационарный ПК (приставка), то бывает он просто вырубается. Хотя в настройках энергосбережения поставил все как надо. Дергать нужно ребят, чтобы они включали его вживую и смотрели, чтобы докер (автозапуск на него настроил) был включен.
Если бы была vps то было бы проще в этом плане.
Если есть мысли, как получать доступ к такой выключенной машине из внутреннего контура, как к ВПС, чтобы включать ее когда нету питания, то, пожалуйста, делитесь - попробую интегрировать)
2) У нас нету LDAP. Хотя потенциал внедрить есть. И за такой автоматизацией явно были бы плюсы и удобства. Хотя по идее можно что-то кастомное на VW накатить, чтобы по api и ldap внутренним общалось. Ну тут уже идея ради идеи, проще было бы что-то купить.
3) Ну и ещё минус extension от Bitwarden на self-hosted не работает на устройствах :/
Как человек, который очень много работал с mTLS: VPN в качестве сетевой изоляции почти всегда можно заменить на грамотно настроенный вебсервер с mTLS. Да, для этого нужно хорошо понимать x509, но окупается сторицей, особенно в российских реалиях, где один VPN почти наверняка уже включён.
А нельзя разве приложение скачать на телефон? Там будут кешированные данные храниться с паролями.
Уже более года пользуемся vaultwarden примерно по описанной в статье схеме. Что хочу отметить (в основном, косяки Bitwarden и связанные с ним, но тем не менее):
Несколько неочевидная система приглашения: на почту уходит ссылка, пользователь нажимает на неё, но после этого не получает доступ в организацию, а попадает в лимб, где администратору нужно зайти и прокликать принятие принятия им приглашения.
Вложенные коллекции — это больно. Доступ на коллекции не транзитивный, если дать доступ на родительскую коллекцию, то это не будет автоматически выдавать доступ на дочерние. Да, сесурити. Но сильно мешает, когда этих коллекций за дюжину и более.
Vaultwarden нельзя использовать в, собственно, качестве vault для хранения и доставания токенов и прочего. Можно возиться с bw cli и парсить его вывод, можно попытаться пропатчить SDK, но мы пытались прикрутить его к ansible-деплоям и выяснилось, что для этого придётся форкать, фиксить и поддерживать форк SDK.
Недавно они сломали обратную совместимость на плагинах, из-за чего пришлось удалять и переустанавливать браузерный плагин. Когда контора маленькая, то это нормально, но я представляю лицо администратора энтерпрайза на 500+ человек.
В остальном: шикарный софт, особенно сейчас, когда он нативно поддерживает переход из KeePass. И выбор SQLite как базы данных вместо MongoDB или Postgres был очень мудрым и сильно облегчил снятие бэкапов/перенос на другую машину.
Как-нибудь у меня дойдут руки и я попробую перенести деплой в кубер, но это будет не сегодня.
Acme закрывается сильно проще через nginx 1.30.x + acme-module. Несколько строчек конфига и головная боль уходит навсегда.
Фундаментально понятно, что секреты надо где-то безопасно хранить. А вот мне интересно другое, сейчас сотрудники часто могут использовать ИИ с корпоративными данными и что VPN, что выделенное хранилище паролей, они сами от внутренней утечки в компании не спасут, сотрудник кинет в харнесс доступы и скажет агенту задеплоить фичу, а сам пойдет чай пить. Как вы боретесь с этим? Локальные модели, запрет на использование ИИ?
Прецедентов не было, да и не вся команда очень продвинутая, а заниматься обучением и евангелизмом нету мотивации . А так регламенты, разграничение доступа для разработчиков и самое главное и не легкое - обучение сотрудников. А так в более крупных компаниях, мне рассказывали, что просто покупают корпоративный аккаунт. Тут есть возможность промониторить чаты. Но если нормально пользоваться агентами и оркестрацией, то хз. Тут наверное более комплексная история, где нужно менять подход к разработке, чтобы создавать изолированные стенды и доступы, чтобы можно было не бояться за такие утечки после использования харнесс истории и т.д.
В разделе про бэкапы, кажется, спряталась довольно неприятная мина.
У вас для ttionya/vaultwarden-backup стоит ZIP_ENABLE: "TRUE", но ZIP_PASSWORD в приведённом compose не задан.
А дефолтный ZIP_PASSWORD у этого образа — буквально WHEREISMYPASSWORD?.
Получается немного символично: корпоративные пароли убрали из Telegram и Excel, настроили VPN, 2FA, два независимых бэкапа и тестовое восстановление — а пароль от архивов опубликован в README используемого Docker image :)
Если в реальном конфиге пароль задан отдельно — я бы обязательно дописал это в статью, потому что сейчас пример довольно легко скопировать буквально.
И у Vaultwarden ORG_EVENTS_ENABLED по умолчанию false, а в вашем .env он не задается, так что утверждение «любой вопрос кто и когда получил доступ к этому паролю закрывается логами», получается, слишком сильное. У него вообще не все с логированием прямо идеально, если уж копаться.
Верно подмечено! Упустил этот момент перед публикацией, брал статью на основе своего runbook . В бою отдельно прописал.
Про беду с логами плюсую. Хотелось побыстрее выкатить , да и я так скажу, что нету мотивация на продвижение каких-то фич. По повода формулировки - тут больше изначальная цель была такой, но по реализации пришлось немножко деградировать в этом направлении из-за описанного выше.
сплошное не А, а В.
Все прочитал. Интересно. Но так и не понял того, что вынесено в заголовок, а именно: "заставил компанию им пользоваться"....
Можете осветит данную проблематику?

Как я поднял self‑hosted менеджер паролей и заставил компанию им пользоваться