Агент Apache Hadoop YARN

Агент YARN — провайдер авторизации ResourceManager: YARN спрашивает его, кто может отправлять в очередь, администрировать очередь и администрировать кластер, и он отвечает по подписанным политикам сервиса данных yarn. Дистрибутив поставляет его как совместимый с Java 8 JAR agents/yarn/grantforge-agent-yarn-<version>.jar со встроенными и перемещёнными зависимостями.

Интеграционные тесты Testcontainers в репозитории запускают JAR в ResourceManager Hadoop 3.2.4, 3.3.6, 3.4.3 и 3.5.0. Это не сертифицирует все остальные версии. Сервисный плагин описан в Apache Hadoop YARN.

Как это работает

• Каждая проверка решается в каждой очереди пути. Как и в YARN, разрешение на очередь распространяется на очереди под ней, поэтому агент решает отправку в root.sales.etl в root, root.sales и root.sales.etl: запрет в любой из них отклоняет, разрешение в любой из них предоставляет.
• Отправка решается и по имени приложения. В каждой из этих очередей агент спрашивает также об очереди с именем приложения, поэтому политика может принимать только некоторые приложения, например payroll-*, в очередь и очереди под ней.
• Политики могут действовать только для некоторых сетей. Каждая проверка несёт адрес клиента, за прокси — первый переданный, и агент вычисляет условие Адреса клиентов с помощью собственных списков хостов Hadoop.
• Администрирование кластера подчиняется политикам. Административные операции YARN, которые иначе предоставляет yarn.admin.acl, требуют admin на кластере.
• Отказы записываются в журнал с причиной. Текст отказа, который получает клиент, формулирует YARN; журнал ResourceManager называет политику GrantForge, которая запретила, или сообщает, что ни одна не разрешает.
• Решения сохраняются, а обращения объединяются. Решения текущего снимка сохраняются, по умолчанию 100 000 на 10 секунд, а новый снимок начинает заново. Одинаковые разрешённые обращения в пределах окна, по умолчанию 10 секунд, передаются одним событием доступа с указанием их числа; отказы передаются по одному и сразу. Каждое событие называет приложение, очередь и адрес клиента.
• Сам ResourceManager не проверяется. Собственный пользователь ResourceManager, например yarn, не проверяется и не аудируется.

Развёртывание

1. Добавьте сервис данных yarn и настройте его политики. Откройте Права доступа к данным → Агенты, выберите сервис и выпустите токен агента. Он показывается только один раз; сохраните его в файл, доступный для чтения только учётной записи YARN.

2. Скопируйте JAR в share/hadoop/yarn/lib каждого ResourceManager, например /opt/hadoop/share/hadoop/yarn/lib.

3. Добавьте параметры в yarn-site.xml каждого ResourceManager, заменив адрес, пути, пользователя и имя экземпляра из примера:

   <configuration>
     <property>
       <name>yarn.acl.enable</name>
       <value>true</value>
     </property>
     <property>
       <name>yarn.authorization-provider</name>
       <value>org.devlive.grantforge.yarn.agent.GrantForgeYarnAuthorizer</value>
     </property>
     <property>
       <name>yarn.admin.acl</name>
       <value>yarn</value>
     </property>
     <property>
       <name>grantforge.server.url</name>
       <value>https://grantforge.example.com</value>
     </property>
     <property>
       <name>grantforge.token.file</name>
       <value>/etc/hadoop/grantforge.token</value>
     </property>
     <property>
       <name>grantforge.instance</name>
       <value>resourcemanager-1</value>
     </property>
     <property>
       <name>grantforge.cache.dir</name>
       <value>/var/lib/hadoop-yarn/grantforge-cache</value>
     </property>
   </configuration>

   yarn.admin.acl должен называть только собственного пользователя ResourceManager: YARN позволяет своим администраторам делать что угодно с любым приложением ещё до того, как спросит агента об очереди. Каталог кэша должен быть доступен для записи учётной записи YARN.

4. Перезапустите ResourceManager по одному. Пока агент не получит первый снимок, запросы, кроме запросов самого ResourceManager, отклоняются.

5. Сначала перенесите существующие права: ACL очередей в конфигурации планировщика, например acl_submit_applications и acl_administer_queue, перестают действовать. Заранее создайте соответствующие политики.

Пользователи, группы и роли

Политики называют короткое имя, которое YARN даёт вызывающему: имя пользователя при простой аутентификации или короткое имя принципала Kerberos по hadoop.security.auth_to_local. Группы — это группы, которые сопоставление групп Hadoop даёт пользователю на ResourceManager, вместе с группами, в которые пользователя помещает GrantForge; роли — те, что назначает ему GrantForge.

Решения и ограничения

• Без пригодного снимка отклоняется всё, кроме собственных запросов ResourceManager. Неиспользуемый сервис оставляет YARN без проверок, как при выключенном yarn.acl.enable.
• Токен, привязанный к сервису, тип которого не yarn, отклоняет всё.
• YARN спрашивает о своём администрировании без адреса клиента, поэтому условие «Адреса клиентов» на cluster никогда не выполняется.
• Владелец приложения и пользователи, указанные в его собственных ACL, управляют им независимо от политик, как и в YARN.
• Проверки других типов доступа, например ACL приоритетов приложений, отклоняются.
• Имя хоста в условии «Адреса клиентов» требует разрешения имени клиента каждый раз, когда решение принимается, а не берётся из сохранённых.
• Решения сохраняются на grantforge.decision.cache.ttl.ms, поэтому политика начинает или перестаёт действовать с задержкой до этого времени.

Связанные руководства

• Apache Hadoop YARN
• Сервисы данных, политики и агенты