LUKS on LVM or LVM on LUKS

Не очень понятно, что именно имеется в виду под «Можно ограничиться LVM и сделать несколько LUKS». Посмотрите ниже - я Вас правильно понял?

Такая схема вас устроит?

sda -> luks1 -> pv1 -> vg
sdb -> luks2 -> pv2 -> vg

vg -> lv1 -> vm1 
vg -> lv2 -> vm1
vg -> lv3 -> vm2

Или нужен ещё слой шифрования?

В целом - можете озвучить угрозы, от которых Вы защищаетесь? Безопасность часто идёт в разрез с удобством, поэтому нужно понимать именно требования безопасности и от них плясать.

Угроза физического стыривания дисков) Имел ввиду, с схд на виртуалку приведу диск, n-го объёма. В вашей схеме, два разных девайса, два LUKS, 1 VG, т.е. объединяете два диск в группу, по сути объём sda+sdb, а потом нарезка на LV. Правильно ли я Вас понял? Не проще ли будет приводить диски на виртуалку, делать 1 диск 1 pv-vg-lv 1 luks, чтобы не было путаницы? И в случае расширения пространства делать resize.

Угроза физического стыривания дисков)

Из СХД? Кстати, может быть, у самой СХД есть средства шифрования?

Имел ввиду, с схд на виртуалку приведу диск, n-го объёма.

Понятно.

В вашей схеме, два разных девайса, два LUKS, 1 VG, т.е. объединяете два диск в группу, по сути объём sda+sdb, а потом нарезка на LV. Правильно ли я Вас понял?

Да.

Не проще ли будет приводить диски на виртуалку, делать 1 диск 1 pv-vg-lv 1 luks, чтобы не было путаницы? И в случае расширения пространства делать resize.

Я вижу два варианта, в зависимости от требований по доступности.

Вариант 1: можно спокойно выключить виртуалку и провести обслуживание в любой момент.

• делаете схему LUN -> LUKS (то есть смысла в LVM я здесь вообще не вижу).
• когда понадобится увеличить раздел:
  • останавливаете VM
  • увеличиваете LUN
  • запускаете VM
  • делаете ресайз FS (и таблицы разделов, если используете внутри FS)

Вариант 2: нужно увеличивать размер дисков без остановки VM.

• делаете схему LUN1 -> LUKS1 -> PV1 -> VG -> LV
• когда понадобится увеличить раздел:
  • добавляете LUN2 -> LUKS2 -> PV2 -> VG -> увеличиваете LV

В тему: https://www.golinuxcloud.com/resize-luks-partition-shrink-extend-decrypt/

+1. На каждый физическйи диск LUKS (ибо иначе никак). А под LUKS уже LVM, и каждой машине по LV. Можно ещё thin provisioning сделать.

Просто я не совсем понимаю разницу между подходами. Если внутри LUKSa держать LVM то для логической разбивки LV. Но если обратное, то получается на каждый LV делать LUKS. Но если у человека нет необходимости что-то менять. Будет один диск, То разницы, в полезности и бесполезности подходов, нет получается. Только в наборе и порядке команд.

Вариант 2: нужно увеличивать размер дисков без остановки VM.

Я тестово делал так. Внутри LVM LUKS, LV1 делал lvresize, а потом cryptsetup resize.

Проверял с помощью blockdev –getsize64.

Но если обратное, то получается на каждый LV делать LUKS

Это не Ваш кейс, насколько я понимаю.

Потребность так делать может возникнуть, если хочется защититься от специфических рисков. В общем случае делается lvm поверх luks, а не наоборот.

Это не Ваш кейс, насколько я понимаю.

Это в песочнице. Вкурив маны. Я сначала сделал LVM, а потом LUKS. Но, благодаря разнообразным вопросам гуглу, нарыл гайд как делать LUKS, а потом LVM. И тему создал для раскрытия разного рода подводных камней. И до сих пор вкуриваю.

В общем случае делается lvm поверх luks, а не наоборот. Не нашел подтверждения или опровержения. Но если так делают, то есть что-то из-за чего это делают))

В общем случае сгодится lvm на luks.

В общем случае сгодится lvm на luks. В общем случае делается lvm поверх luks, а не наоборот.

Я правильно понимаю, что имеется ввиду одно и то же?

cryptsetup luksFormat /dev/sd* cryptsetup luksOpen /dev/sd* crypt pvcreate /dev/mapper/crypt vgcreate lvm /dev/mapper/crypt lvcreate -n lv1 -l 100%FREE lvm

Сначала LUKS потом LVM в общем случае?

Что я успел подметить. Если использовать привод виртуальных дисков в виртуалку. То если поднять LUKS, а в нём уже LVM. Получается гибкая система, можно в LVM пилить и распиливать. Потом ресайзами баловаться. Но пароль один, мастеркей тоже один, один раз хакнул и всё получил, не самое надёжное решение. НО меня такое вполне устраивает. А если делать LVM, а потом на каждый LV пилить LUKS. Задолбаешься с паролями, но надёжность вырастает.

Но пароль один, мастеркей тоже один, один раз хакнул и всё получил, не самое надёжное решение

Задолбаешься с паролями, но надёжность вырастает.

А от чего ты пытаешься защититься?

От утери/кражи физической. Не самое критичное, но чтоб с ними ничего не сделали.

Одного нормального пароля достаточно.

Всем огромное человеческое спасибо. =)

Сначала LUKS потом LVM в общем случае?

Да.

cryptsetup luksFormat /dev/sd* cryptsetup luksOpen /dev/sd* crypt pvcreate /dev/mapper/crypt vgcreate lvm /dev/mapper/crypt lvcreate -n lv1 -l 100%FREE lvm

В целом да, за исключением параметров lvcreate - создавать один логический том на lvm не имеет смысла.

создавать один логический том на lvm не имеет смысла.

Извиняюсь за ошибку. Данной командой я не совсем это хотел сказать. Вы правы, логичнее иметь не один том. =)