Я не очень хорошо разбираюсь в блеске, так как только вчера начал использовать его.
У меня 2 сервера. Оба работают под управлением glusterfs-серверов.
С сервера 1: бегу sudo glusterfs peer probe server2 и он добавлен в кластер. Никаких вопросов не было. Я ничего не сделал, чтобы сообщить серверу server2 разрешить server1 добавить его в кластер. Для меня это не имеет смысла.
Это меня смущает. Я имею в виду, что если кто-то добавит мои серверы glusterfs в свой кластер. Казалось, что никакой безопасности не было. Это безумие, и я этого не понимаю.
TL, DR: Это безопасно, третья сторона не может присоединиться к существующему кластеру самостоятельно, ее нужно пригласить изнутри.
Никаких вопросов не было. Я ничего не сделал, чтобы сообщить серверу server2 разрешить server1 добавить его в кластер.
У меня сам был этот вопрос, поэтому я пошел посмотреть документацию.
Когда вы создаете новый кластер, вы начинаете с одного сервера и добавляете другие, используя gluster peer probe OTHER_SERVER. Дополнительная безопасность не требуется, поскольку вы добавляете новые неинициализированные серверы glusterfs. (Если только вы оставляете только что установленный, неинициализированный gluster с открытым доступом - тогда у вас проблемы).
Так что же мешает злоумышленнику присоединиться к вашему существующему кластеру? Ключевым является следующий абзац:
Как только этот пул создан, только доверенные члены могут проверять новые серверы в пуле. Новый сервер не может зондировать пул, он должен зондироваться из пула. (источник)
Как сказано в документации, стороннее лицо / злоумышленник не может присоединиться к вашему кластеру, его нужно пригласить изнутри.
Gluster также предоставляет другие механизмы безопасности для защиты от связанных атак:
gluster volume set VOL_NAME auth.allow IP1,IP2Для чего-то важного вы также можете рассмотреть частные ссылки между серверами (IPSec / VPN) с настройкой брандмауэра, которая не допускает никаких подключений извне.
Ваши серверы Gluster должны быть автономными, изолированными от брандмауэра в вашей инфраструктуре. Они не предназначены для публичного доступа в Интернет.
Я согласен, что это безумие: безопасность - это дополнение к glusterfs. Как указывает @ceejayoz, glusterfs предназначен для работы только в физически защищенной и изолированной сети.
К счастью, glusterfs добавил поддержку ssl, которая, к сожалению, почти полностью недокументирована. Предположительно, использование ssl улучшит ситуацию, хотя, поскольку он недокументирован, трудно сказать наверняка. Какая документация существует в этот блог. К сожалению, это всего лишь последовательность шагов.
Я хотел бы добавить в эту тему для справки, потому что у меня тоже изначально были проблемы с безопасностью glusterfs.
Моя организация находится в процессе развертывания довольно большого кластера RHGS для консолидации нескольких рассредоточенных устаревших систем хранения.
Проблемы безопасности, которые у меня были, были связаны с возможностью запускать команды консоли gluster от имени пользователя root из клиентской системы, такой как ...
"yes | gluster --remote-host = rhgs1 удаление данных тома"
Ой! Похоже, что любой человек с привилегиями root в системе, в которой вы не контролируете учетную запись root, может уничтожить ваши данные!
К счастью, это не так. Любая из команд, изменяющих тома, возвращает статус выхода 1 и завершается ошибкой с EPOLLERR, как указано в /var/log/glusterfs/cli.log. Похоже, вы можете получить информацию только о томах, к которым у этого клиента есть доступ.
По сути, система должна быть одноранговым узлом кластера, чтобы иметь возможность выполнять задачи обслуживания кластера с любого из узлов кластера. Теперь я понимаю, почему они называют кластер glusterfs «защищенным пулом хранения».
На мой взгляд, есть несколько способов решить проблему: