Обзор Resource Mapping Manager
Часто различным задачам для работы требуются одни и те же данные — некоторым из них требуется аутентификация на уровне таблицы или БД (запросы Hive), а другим — на уровне файлов (задачи Spark). Это означает, что пользователь может получать доступ к данным кардинально разными способами, и чтобы эти данные оставались в безопасности, необходим механизм создания и поддержания различных политик Ranger для всех сервисов, способных управлять этими данными (например, Hive или HDFS).
При изменении политики для таблицы Hive администратор данных должен сделать идентичное изменение в соответствующей политике HDFS. Если этого не сделать, то возникает риск раскрытия данных и других проблем с безопасностью. Администратор данных должен создать единую политику для таблицы, с которой будут синхронизироваться соответствующие политики доступа к файлам, а также аудиты доступов, относящихся к политике для таблицы.
Для разрешения этих проблем в ADPS 2.0.0 был разработан механизм Ranger Resource Mapping. На данный момент он поддерживает соответствие ресурсов между сервисами Hive и HDFS, а также Hive и Ozone.
Ranger Resource Mapping Manager (RMM) отвечает за получение изменений в сопоставлении ресурсов из внешних сервисов (например, Hive Metastore), их фильтрацию и сохранение соответствующих событий в таблицу x_resource_mapping_diff базы данных Ranger. В текущей версии RMM в качестве источника изменений в сопоставлении ресурсов поддерживается только Hive Metastore.
Hive chained plugin
Ranger позволяет базовым плагинам при необходимости делегировать запрос авторизации списку так называемых chained-плагинов. Если базовый плагин разрешает доступ, а один из chained-плагинов — нет, то доступ будет запрещен.
В рамках этой функции реализован chained-плагин Hive для добавления дополнительного уровня авторизации к плагинам HDFS и Ozone:
-
Когда срабатывает базовый плагин и доступ разрешен, он вызывает один из методов chained-плагина Hive.
-
Конкретная реализация chained-плагина Hive (HDFS или Ozone) извлекает запрашиваемый путь из запроса и преобразует тип доступа к базовому сервису в тип доступа Hive.
-
Chained-плагин Hive сопоставляет путь с сущностью Hive (БД или таблицей) и формирует из него запрос на доступ к Hive.
-
Chained-плагин Hive вызывает соответствующий метод плагина Ranger для Hive с созданным запросом на доступ.
Получение метаданных из Hive
Получение данных из Hive Metastore происходит в два этапа: создание снепшота (опционально) и прослушивание событий (обязательно).
Создание снепшота
При первом запуске или при перезапуске с значением true параметра ranger.rmm.hms.sync.full RMM выполняет следующие действия:
-
Очистка таблицы
x_resource_mapping_diff. -
Создание снепшота текущего состояния Metastore.
-
Внесение текущих БД и таблиц в таблицу сопоставления ресурсов.
Прослушивание событий
Процесс получения метаданных переходит в состояние прослушивания событий в двух случаях:
-
Если в таблице
x_resource_mapping_diffесть изменения и параметрranger.rmm.hms.sync.fullне имеет значения или имеет значениеfalse. -
Если завершен этап создания снепшота, описанный выше.
Hive предоставляет API для прослушивания различных событий, происходящих в Metastore. Уведомления о событиях содержат уникальное поле eventId с монотонно увеличивающимися значениями, которые используются RMM в качестве внешних ID изменений в сопоставлениях. Hive позволяет получать либо все события, либо только произошедшие после последнего события, полученного клиентом. Таким образом, хранение eventId последнего полученного элемента означает подписку только на новые события в Metastore. После перезапуска RMM получает из таблицы x_resource_mapping_diff самое большое значение ID и использует его в качестве ID последнего полученного события.
Обрабатываются только следующие типы событий как для БД, так и для таблиц:
-
создание сущности;
-
удаление сущности;
-
переименование сущности;
-
изменение местоположения сущности.
Остальные события игнорируются.