Как реализации MPI (OpenMPI, MPICH) обрабатывают безопасность / аутентификацию

Question

Как OpenMPI и MPICH управляют безопасностью, когда я посылаю сообщения MPI между процессами через сокеты TCP / IP?

В частности, как они запрещают другим пользователям той же сети подключаться к прослушивающему сокету и отправлять поддельные сообщения MPI?

Конкретный сценарий выглядит следующим образом:

• Администраторам доверяют. Ненадежные пользователи не имеют физического доступа к любому оборудованию или сети. Ненадежные пользователи не имеют root-доступа.
• Однако недоверенные пользователи могут запускать свои собственные программы в кластере; узлы кластера - это типичные блоки Linux. В частности, ненадежные пользователи могут открывать TCP-соединения с любого компьютера на любом другом компьютере в кластере и отправлять произвольные сообщения.

Answer 1

J Теллер справа; MPI на самом деле этого не делает, и не должен. Это проектное решение, основанное на сценарии использования MPI.

Пользователи MPI - это те люди, которые платят много денег за межсоединения с задержкой менее микросекунды. Затраты на какое-либо криптографическое подписание сообщений были бы совершенно неприемлемыми для этого сообщества.

И это не очень поможет. MPI используется в качестве интерфейса передачи сообщений в контролируемой среде - узлах в кластере с ограниченным доступом или, возможно, машинах в вычислительной лаборатории. Если злонамеренный пользователь получает достаточный контроль над одним из этих узлов, чтобы помешать обмену данными MPI, есть гораздо более простые способы прервать обмен данными, чем перехватывать пакеты, выяснить, какая стадия вычисления находится в стадии выполнения, и выполнить какую-то работу человека. средняя атака. Можно просто изменить память запущенного задания или, проще, просто перезаписать результаты в общей файловой системе. (можно просто заметить, что отправка поддельных сообщений MPI может произойти, поскольку «реальные» сообщения будут накапливаться, используя ресурсы и, возможно, сбивая задание; аналогично, перехват сообщений без их передачи почти наверняка приведет к тупику).

Эти аргументы не слишком применимы к распределенным вычислениям, конечно, скажем, в стиле BOINC, но MPI в любом случае не очень подходит для такого рода использования.

Ничто, конечно, не останавливает пользователя MPI, у которого есть такого рода требования безопасности, от простой отправки подписи в стиле pgp вместе с каждым сообщением и включения ее в свой код; но механизм для этого сам по себе не является частью MPI, и это, безусловно, правильное решение.

Answer 2

Я не совсем эксперт в этом вопросе, но основной ответ заключается в том, что MPI обычно не поддерживает безопасность. Он полагается на базовую ОС для обеспечения уровня безопасности, который вы описываете.

В моем дистрибутиве mpi встроено использование демона mpd (демона, запускающего процессы mpi). mpdboot нормальным образом устанавливает кольцо демонов mpd в кластере (по 1 на узел). Как только это кольцо настроено, и если вы доверяете демонам mpd, то все готово. Mpd позаботится о том, чтобы только ваши собственные процессы подключались к вашим процессам mpi.

Тем не менее, я не совсем понимаю «нормальный путь», когда настроено кольцо mpd. Однако в моем дистрибутиве mpdboot - это скрипт на python, поэтому можно посмотреть на него и посмотреть, достаточно ли он безопасен для вас. Вероятно, достаточно безопасно, если кластер, на котором вы работаете, контролируется доступом.

Answer 3

Я полностью согласен с @Jonathan Dursi, который говорит, что защита связи MPI вносит незначительный вклад в безопасность хорошо настроенного кластера, но (a) руководство может настаивать, (b) по какой-то причине вы хотите запустить MPI в ненадежной сети, и (с) решить проблему весело.

Что касается ситуации с ненадежной сетью, я ранее использовал IPSec для защиты сети связи MPI в кластере. Вместо использования сценариев автоматической настройки IPSec, для которых требуются сертификаты, я загружал симметричные ключи шифрования через сценарий оболочки, который автоматически создавался с помощью сценария python.

Чтобы изолировать взаимодействие MPI отдельных заданий в кластере, должна быть возможность расширить этот подход для загрузки вновь сгенерированных ключей IPSec в прологе каждого задания, а не только один раз при запуске системы. В этой настройке задания не должны совместно использовать узлы. Кроме того, будет проще настроить это с выделенной сетью для MPI, так как текущие соединения (ssh, менеджер заданий и т. Д.) Должны быть оставлены нетронутыми, и вы, вероятно, не хотите включать головной узел (узлы), который обычно Система управления заданиями должна подключаться к сети IPSec задания, поскольку злоумышленник может находиться там.