Мы хотим поддержать этот сценарий: если мы чувствуем какую-либо угрозу безопасности, которая может раскрыть наши основные данные (все хранящиеся на /home NFS монтируется с нашего сервера NFS), мы немедленно "жестко" выключаем сервер NFS. Любая возможная, последовательная, несанкционированная перезагрузка сервера не может читать и писать в /home... потому что наша система (надеюсь) потребует пароль / key_challenge / secret от человека (как первоначально предложено ниже), возможно, если не вероятно, через простой вход ssh на сервер NFS, прежде чем система сможет смонтировать /home объем.
Возможно ли это, и если да, то как это сделать? Является ли это режимом «нормальный / по умолчанию» для креплений на базе LUKS (или какой-либо подобной технологии, набора инструментов, приспособлений)? И / или есть альтернативные (лучшие?) Способы передать наши намерения?
Моя команда планирует реализовать Экспорт NFS из LUKS-файл типа "разреженный файл" петлевого устройства., похожий или точно такой же /home экспорт (для подключения клиента NFS к другим серверам / машинам / виртуальным машинам / контейнерам в нашей VPN / сети).
Наша текущая целевая реализация: требуется пароль (или запрос на основе ключа), прежде чем система сможет смонтировать LUKS /home объем (только при монтировании с сервера NFS), предположительно после нормальной загрузки машины / контейнера с NFS-сервером.
Однако, если есть способ получше ... пожалуйста, предложите это. Мы хотим предоставить цель / намерение, описанные в резюме, наилучшим возможным способом (-ами), а не предполагать ограниченный набор потенциальных решений.
В настоящее время мы ожидаем, что сервер NFS будет контейнером Docker Ubuntu 18.04.4, работающим на хосте докеров Ubuntu той же версии. А точки монтирования, экспортированные по NFS, будут томами Docker, обслуживаемыми хостом Docker (в контейнер NFS Docker). Но этот дизайн далек от «набора», и мы гибки и открыты для альтернативных предложений.
И хотя мы действительно обслуживаем приложение NFS (проект системы), использующее отображение петлевых устройств («файловая система в файле», как мы это понимаем), мы еще не рассматриваем это как NFS- или петлевое устройство - конкретная проблема. то есть такой же сценарий может возникнуть для других проектов без компонентов NFS или петлевых устройств.
В нашей текущей среде мы НЕ можем использовать решения, подобные SAN. (Мы понимаем, что LUKS, встроенные в решения для сетевых хранилищ / SAN, популярны в настоящее время. Мы получили много комментариев, похожих на «просто используйте SAN на основе LUKS». В данном случае это не сработает.) Наше текущее ограничение : эта установка NFS-сервера работает в на базе kvm виртуальная машина, обычно развертываемая провайдером хостинга, например DigitalOcean, Linode, AWS и т. д.
Да, мы понимаем, что резкое отключение / некорректное завершение работы сервера NFS приведет к поломке всех клиентов NFS; мы планируем потребовать, чтобы все они были перезагружены (в худшем случае). И да, мы понимаем, что некорректное завершение работы может изменить данные, файловые системы, базы данных и т. Д.
Мы спроектировали нашу сеть так, чтобы она надежно и (относительно) легко справлялась со всеми этими сценариями в разумных пределах. Далее: мы ожидаем, что 1) этот сценарий «аварийного выключателя» будет редко случается, и 2) нам редко приходится перезагружать систему сервера NFS (контейнер Docker или иначе) по какой-либо причине; мы сохраним его стабильность и разместим все наши более динамично изменяющиеся программные системы (ОС, приложения и т. д.) на других машинах. Сервер NFS получает небольшую блокировку конфигурации и сверхпростую настройку с несколькими зависимостями.
В любом случае, мы подписываемся на все, что влечет за собой эта установка, поскольку мы обладаем значительным опытом работы с блочными и файловыми системами, администраторами серверов хранения (задолго до появления LUKS) и «работали в этом блоке», по крайней мере, с давным-давно. (В частности, от эпохи до Fibre-Channel-SAN и пост-FC-SAN с середины 1990-х до начала 2000-х, до того, как Linux «стал большим». Немного больше системного опыта в конце 2000-х - начале 2010-х.)
И хотя мы опытные, седые ветераны былых времен, мы также новички LUKS. Тем не менее, все концепции LUKS кажутся простыми с аналогичными системами, которыми мы управляли ранее. Наше первоначальное исследование показывает, что есть много вопросов по StackExchange / ServerFault, в которых конкретно задаются вопросы о том, как избегать необходимость вручную вводить пароль / key_challenge / secret. Фактически (как мы думаем?) Мы хотим сделать наоборот. И прежде чем мы приступим к реализации всего этого, мы публикуем этот вопрос в надежде, что сможем поучиться у тех, кто работал до нас, и, возможно, сэкономить немного времени на проекте.