Я не действительно хорош в gluster, когда я только что начал использовать это вчера.
У меня есть 2 сервера. Оба выполняют glusterfs-серверы.
С сервера 1: Я работаю sudo glusterfs peer probe server2
и это добавляется к кластеру. Не было никаких вопросов, которые задают. Я не сделал ничего, чтобы сказать server2 позволять server1 добавлять его к кластеру. Не имеет смысла мне.
Это смущает меня. Я имею в виду, что, если кто-то добавляет мои glusterfs серверы к их кластеру. Походивший не было абсолютно никакой безопасности. Это безумно, и я не получаю его.
TL, DR: Это безопасно, третья сторона не может присоединиться к существующему кластеру самостоятельно, ее нужно пригласить изнутри.
Не было задано никаких вопросов. Я ничего не сделал, чтобы сообщить серверу server2 разрешить серверу 1 добавить его в кластер.
У меня сам был этот вопрос, поэтому я пошел взглянуть на документацию.
Когда вы создаете новый кластер, вы начинаете с одного сервер и добавить другие, используя зонд узла gluster 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 volume delete data»
Ура! Похоже, что любой человек с привилегиями root в системе, в которой вы не управляете учетной записью root, может уничтожить ваши данные!
К счастью, это не так. Любая из команд, изменяющих тома, возвращает статус выхода 1 и завершается ошибкой с EPOLLERR, как указано в /var/log/glusterfs/cli.log. Похоже, вы можете получить информацию только о томах, к которым у этого клиента есть доступ.
По сути, система должна быть одноранговым узлом кластера, чтобы иметь возможность выполнять задачи обслуживания кластера с любого из узлов кластера. Теперь я понимаю, почему они называют кластер glusterfs «защищенным пулом хранения».