Конференция Arenadata
Новое время — новый Greenplum
Мы приглашаем вас принять участие в конференции, посвященной будущему Open-Source Greenplum 19 сентября в 18:00:00 UTC +3. Встреча будет проходить в гибридном формате — и офлайн, и онлайн. Онлайн-трансляция будет доступна для всех желающих.
Внезапное закрытие Greenplum его владельцем — компанией Broadcom - стало неприятным сюрпризом для всех, кто использует или планирует начать использовать решения на базе этой технологии. Многие ожидают выхода стабильной версии Greenplum 7 и надеются на её дальнейшее активное развитие.
Arenadata не могла допустить, чтобы разрабатываемый годами Open-Source проект Greenplum прекратил своё существование, поэтому 19 сентября мы представим наш ответ на данное решение Broadcom, а участники сообщества получат исчерпывающие разъяснения на все вопросы о дальнейшей судьбе этой технологии.

На конференции вас ждёт обсуждение следующих тем:

  • План возрождения Greenplum;
  • Дорожная карта;
  • Экспертное обсуждение и консультации.
Осталось до события

Плагины Ranger

Плагин Ranger — это ПО, позволяющее интегрировать сервис, для которого разработан плагин, с Ranger. Подобные плагины позволяют Ranger Admin контролировать доступ посредством политик. В данной статье описывается структура плагинов, а также их взаимодействие с Ranger. В статье Архитектура Ranger представлена схема, показывающая как плагины подключаются к Ranger, а также отправляют логи в Solr.

Структура

Плагин Ranger состоит из двух частей:

  • Серверная часть — компонент, находящийся на стороне Ranger.

  • Часть на стороне приложения — компонент, находящийся на стороне сервиса и взаимодействующий с серверной частью для определения наличия необходимых прав у пользователя на запрошенный ресурс.

Ниже представлено подробное описание каждой части.

Серверная часть

Серверная часть состоит из конфигурационного файла в формате JSON и имплементации класса, наследующего RangerBaseService.

Конфигурация сервиса

Конфигурационный файл содержит некоторую мета-информацию, но также и несколько важных разделов:

  • Ресурсы. В данном блоке описываются ресурсы создаваемого сервиса (их названия, типы, ярлыки и т.д.)

  • Типы доступа. Здесь указывается информация о том, какие действия доступны для созданных ресурсов.

  • Настройки. Информация в этом блоке отражает поля для пользовательского ввода.

Типовая структура файла конфигурации для сервиса представлена ниже:

{
    "id": "<service_id>",
    "name": "<service_name>",
    "implClass": "<service_class>",
    "label": "<service_label>",
    "description":"<service_description>",
    "resources": [
        {
            "itemId": 1,
            "name": "<resource_name>",
            "type": "<resource_type>"
        }
    ],
    "accessTypes": [
        {
            "itemId": 1,
            "name": "<action_name>",
            "label": "<action_label>"
        }
    ],
    "configs": [
        {
            "itemId": 1,
            "name": "<config_field_name>",
        }
    ],
    "enums": [ ],
    "contextEnrichers":[ ],
    "policyConditions":[ ]
}
ПРИМЕЧАНИЕ
Заметьте, что цель примера выше — показать структуру файла, поэтому многие необходимые для работы поля не указаны.

Имплементация класса

Наследник класса RangerBaseService ожидает перегрузки двух методов: validateConfig и lookupResource. Первый проверяет значения, полученные в поле configs файла конфигурации сервиса, а второй позволяет работать автодополнению для ресурсов при создании политики в Ranger Admin UI.

Для связи конфигурационного файла с классом, реализующим нужные функции, используется поле implClass.

Часть на стороне приложения

На стороне приложения находится лишь класс для авторизации Ranger. Такой класс общается с серверной частью плагина и проверяет наличие у пользователя прав на совершение некоторой операции.

Принцип работы типового класса представлен ниже:

  1. Создание запрашиваемого ресурса.

  2. Создание запроса с помощью класса RangerAccessRequest. Помимо прочего, запрос содержит в себе запрашиваемый ресурс, имя пользователя и действие, которое пользователь пытается выполнить.

  3. Запрос отправляется на серверную часть с помощью метода isAccessAllowed класса RangerBasePlugin.

  4. Ответ проверяется на наличие у пользователя необходимых прав, после чего происходит выполнение действия или отказ.

Для корректной работы класса RangerBasePlugin необходимо разместить файлы ranger-<service-name>-security.xml и ranger-<service-name>-audit.xml рядом с классом.

Доступные плагины

На данный момент доступны плагины Ranger для некоторых сервисов ADH, ADPS и ADS.

Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней