Главная
Arenadata Platform Security
Базовые операции
Ranger
Примеры использования
Настройка политик

Примеры настройки политик в Ranger

Сергей Тихомиров

Содержание

Обзор
Политики, основанные на геолокации
Политики, зависящие от времени
- Обновление конфигурации сервиса
- Создание/редактирование политики
Кастомные условия

Обзор

Политики Ranger — это удобный способ управления доступом. В данной статье приведено немного информации об условиях доступа, а также примеры сложных политик. О настройках простых политик, а также других действиях с ними, вы можете прочитать в статье Управление политиками в Ranger.

Для создания сложных политик Ranger требуется обновить настройки сервиса в Ranger, что может быть выполнено только через REST API. Для создания некоторых политик требуется добавить context enricher, позволяющий Ranger получать больше информации с запросом доступа. Доступны следующие виды context enricher:

RangerFileBasedGeolocationProvider — добавляет к запросу информацию о геопозиции, из которой пришел запрос на доступ.
RangerGdsEnricher — добавляет к запросу информацию о датасетах, ресурсах в этих датасетах, а также доступах, разрешенных между датасетами.

Для передачи кастомной информации с запросом вы можете создать свой собственный context enricher, реализовав методы интерфейса RangerContextEnricher.

Для добавления дополнительных условий доступа требуется обновить секцию policyConditions в настройках сервиса. Для определения условия доступа нужно указать вычислитель условия (condition evaluator) и опционально параметры вычислителя (evaluator options). Доступны следующие вычислители:

RangerAccessedFromClusterCondition — проверяет название кластера, из которого пришел запрос.
RangerAccessedFromClusterTypeCondition — проверяет тип кластера, из которого пришел запрос.
RangerAccessedNotFromClusterCondition — условие, обратное RangerAccessedFromClusterCondition.
RangerAccessedNotFromClusterTypeCondition — условие, обратное RangerAccessedFromClusterTypeCondition.
RangerAnyOfExpectedTagsPresentConditionEvaluator — проверяет, есть ли на ресурсе какие-то из требуемых для доступа тегов.
RangerContextAttributeValueInCondition — проверяет, есть ли значение в заданном белом списке.
RangerContextAttributeValueNotInCondition — условие, обратное RangerContextAttributeValueInCondition.
RangerHiveResourcesAccessedTogetherCondition — проверяет, можно ли разрешать одновременный доступ к набору ресурсов.
RangerHiveResourcesNotAccessedTogetherCondition — условие, обратное RangerHiveResourcesAccessedTogetherCondition.
RangerIpMatcher — проверяет, можно ли IP-адресу, с которого пришел запрос, разрешить доступ к ресурсу.
RangerNoneOfExpectedTagsPresentConditionEvaluator — проверяет, что ресурс не содержит ни одного из требуемых для доступа тегов.
RangerScriptConditionEvaluator — вычисляет условие, написанное на JS.
RangerTagsAllPresentConditionEvaluator — проверяет, содержит ли ресурс все теги, необходимые для доступа.
RangerTimeOfDayMatcher — проверяет, что запрос пришел в разрешенный промежуток времени.

Перечисленные выше условия можно комбинировать для создания сложных политик. Ниже приведены примеры использования некоторых из условий.

Политики, основанные на геолокации

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

Подготовка

Подготовьте текстовый файл с информацией о разрешенных IP-адресах для указанных локаций. Например:

IP_FROM,IP_TO,COUNTRY_CODE,COUNTRY_NAME,REGION,CITY
91.108.240.1,91.108.240.45,FR,France,Ile-de-France,Paris

Здесь значение IP_FROM означает начало диапазона IP-адресов, а IP_TO — конец диапазона. Остальные поля уточняют, для какой локации применимо ограничение диапазона адресов. Данный файл следует разместить на хосте с Ranger Admin в директории, доступной Ranger для чтения, например, /etc/ranger/geo-data.txt.

Обновление настроек сервиса

Требуется обновить файл конфигурации для необходимого сервиса. Ниже описаны действия для обновления конфигурации сервиса HBase:

Получите текущую конфигурацию:
```
$ curl --user <admin_user>:<admin_pwd> --get "http://<ranger_host>/service/public/v2/api/servicedef/name/hbase"
```
где <admin_user> и <admin_pwd> — данные пользователя Ranger с правами администратора, а <ranger_host> — URL хоста Ranger с портом (6080 — для HTTP, 6082 — для HTTPS).

В качестве ответа вы должны получить JSON-строку с конфигурацией сервиса.

Измените полученный JSON, добавив в него следующую секцию:

"contextEnrichers": [
  {
    "enricher": "org.apache.ranger.plugin.contextenricher.RangerFileBasedGeolocationProvider",
    "enricherOptions": {
      "FilePath": "/etc/ranger/geo-data.txt",
      "IPInDotFormat": "true"
    }
  }
]

FilePath должен содержать путь к файлу с информацией об IP-адресах, созданному ранее.

Добавьте в поле policyConditions следующие строки, чтобы иметь возможность использовать условие доступа по геолокации:
```
{
  "itemId": 2,
  "name": "location-inside",
  "label": "Requested from inside of the location",
  "description": "Enter location",
  "evaluator": "org.apache.ranger.plugin.conditionevaluator.RangerContextAttributeValueInCondition",
  "evaluatorOptions": {
  "attributeName": "LOCATION_COUNTRY_CODE"
  }
}
```
Также вы можете добавить обратное условие:
```
{
  "itemId": 3,
  "name": "location-outside",
  "label": "Requested from outside of the location",
  "description": "Enter location",
  "evaluator": "org.apache.ranger.plugin.conditionevaluator.RangerContextAttributeValueNotInCondition",
  "evaluatorOptions": {
  "attributeName": "LOCATION_COUNTRY_CODE"
  }
}
```
Можно заметить, что значение параметра attributeName начинается на LOCATION_ и заканчивается названием одного из столбцов из файла с информацией про IP-адреса. Префикс LOCATION_ необходимо использовать, т.к. он автоматически добавляется context enricher.
Отправьте обновленную конфигурацию в Ranger Admin:
```
$ curl -i -H "Content-Type: application/json" --user <admin_user>:<admin_pwd> -X PUT --data '<json>' "http://<ranger_host>/service/public/v2/api/servicedef/name/hbase"
```
Ожидается, что JSON представлен в виде одной строки (без знаков переноса). Чтобы этого добиться, можно воспользоваться сервисом JSON Minifier. Вместо строки вы также можете отправить JSON-файл. Ожидаемый ответ содержит HTTP-код 200 OK, некоторую метаинформацию и новую конфигурацию сервиса.

Создание/редактирование политики

Вы можете создать/обновить политику с помощью REST API, но пример ниже демонстрирует как это сделать в веб-интерфейсе:

При создании новой политики следуйте шагам, описанным в разделе Добавление политики. Если вы хотите изменить существующую политику, следуйте шагам в разделе Редактирование политики.
В секции условий доступа появились новые формы ввода.

Новые условия

Новые условия

Установите нужное условие. В данном примере происходит проверка по коду страны.

Условие доступа по геолокации

Условие доступа по геолокации
После добавления всех необходимых условий нажмите Add (или Save) внизу страницы.

Политики, зависящие от времени

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

Обновление конфигурации сервиса

Получите текущую конфигурацию:
```
$ curl --user <admin_user>:<admin_pwd> --get "http://<ranger_host>/service/public/v2/api/servicedef/name/hbase"
```
где <admin_user> и <admin_pwd> — данные пользователя Ranger с правами администратора, а <ranger_host> — URL хоста Ranger с портом (6080 — для HTTP, 6082 — для HTTPS).

В качестве ответа вы должны получить JSON-строку с конфигурацией сервиса.

Добавьте в секцию policyConditions следующие строки, чтобы иметь возможность использовать условие доступа по времени:

{
  "itemId": 4,
  "name": "time-frame",
  "label": "Requested within the time frame",
  "description": "Enter time frame",
  "evaluator": "org.apache.ranger.plugin.conditionevaluator.RangerTimeOfDayMatcher",
}

Отправьте обновленную конфигурацию в Ranger Admin:
```
$ curl -i -H "Content-Type: application/json" --user <admin_user>:<admin_pwd> -X PUT --data '<json>' "http://<ranger_host>/service/public/v2/api/servicedef/name/hbase"
```
Ожидается, что JSON представлен в виде одной строки (без знаков переноса). Чтобы этого добиться, можно воспользоваться сервисом JSON Minifier. Вместо строки вы также можете отправить JSON-файл. Ожидаемый ответ содержит HTTP-код 200 OK, некоторую метаинформацию и новую конфигурацию сервиса.

Создание/редактирование политики

При создании новой политики следуйте шагам, описанным в разделе Добавление политики. Если вы хотите изменить существующую политику, следуйте шагам в разделе Редактирование политики.
В секции условий доступа появились новые формы ввода.

Новое условие

Новое условие

Установите условие. Условие ожидает выражение в формате {HH:MM} AM - {HH:MM} PM, например, 9:30 AM - 3:15 PM.

Условие доступа по времени

Условие доступа по времени
После добавления всех необходимых условий нажмите Add (или Save) внизу страницы.

Результат работы такой политики можно увидеть на вкладке Access секции Audits.

Кастомные условия

По умолчанию некоторые сервисы Ranger включают условие RangerScriptConditionEvaluator. Для других (например, Knox) можно его включить с помощью изменения конфигурации сервиса:

Получите текущую конфигурацию:
```
$ curl --user <admin_user>:<admin_pwd> --get "http://<ranger_host>/service/public/v2/api/servicedef/name/knox"
```
где <admin_user> и <admin_pwd> — данные пользователя Ranger с правами администратора, а <ranger_host> — URL хоста Ranger с портом (6080 — для HTTP, 6082 — для HTTPS).

В качестве ответа вы должны получить JSON-строку с конфигурацией сервиса.

Добавьте в секцию policyConditions следующие строки, чтобы иметь возможность использовать кастомное условие:

{
  "itemId": 2,
  "name": "_expression",
  "evaluator": "org.apache.ranger.plugin.conditionevaluator.RangerScriptConditionEvaluator",
  "evaluatorOptions": {
    "ui.isMultiline": "true"
  },
  "label": "Enter boolean expression",
  "description": "Boolean expression"
}

Отправьте обновленную конфигурацию в Ranger Admin:

$ curl -i -H "Content-Type: application/json" --user <admin_user>:<admin_pwd> -X PUT --data '<json>' "http://<ranger_host>/service/public/v2/api/servicedef/name/knox"

Теперь при создании/редактировании политики в разделе условий доступа появилось новое поле. В нем вы можете написать JS-скрипт, который возвращает true или false. В зависимости от ваших нужд, вам может понадобиться context enricher — о том как его добавить, смотрите на втором шаге в секции Политики, основанные на геолокации. В этом скрипте можно обращаться к следующим объектам:

ctx — обработчик контекста, который содержит метаданные из запроса. Для работы с данными доступны следующие методы:
- getUser() — возвращает имя пользователя, отправившего запрос.
- getUserGroups() — возвращает список групп, членом которых является пользователь.
- getClientIPAddress() — возвращает IP-адрес клиента в виде строки.
- getAction() — возвращает информацию о запрошенном действии в виде строки.
tag — информация о текущем теге.
tagAttr — словарь, в котором хранится информация об атрибутах тега и их значениях.

Например, вы можете написать условие, ограничивающее доступ определенному пользователю (здесь этот пользователь — hbase):

if (ctx.getUser().equals("hbase")) {
    cts.result = false;
}

JS-выражение

После сохранения политики результат ее работы можно проверить на вкладке Access секции Audits.

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