Apache Hadoop YARN-Agent

Der YARN-Agent ist ein Autorisierungsanbieter des ResourceManagers: YARN fragt ihn, wer an eine Warteschlange übermitteln, eine Warteschlange verwalten und den Cluster verwalten darf, und er antwortet aus den signierten Richtlinien des yarn-Datendiensts. Die Distribution liefert ihn als ein Java-8-kompatibles JAR, agents/yarn/grantforge-agent-yarn-<version>.jar, mit eingebetteten und verschobenen Abhängigkeiten.

Die Testcontainers-Integrationstests des Repositorys führen das JAR in den ResourceManagern von Hadoop 3.2.4, 3.3.6, 3.4.3 und 3.5.0 aus. Das zertifiziert nicht jede andere Version. Das Dienst-Plug-in beschreibt Apache Hadoop YARN.

Funktionsweise

• Jede Prüfung wird in jeder Warteschlange des Pfads entschieden. Wie in YARN umfasst eine Berechtigung auf einer Warteschlange die darunter, daher entscheidet der Agent eine Übermittlung an root.sales.etl in root, root.sales und root.sales.etl: Eine Verweigerung in einer davon lehnt ab, eine Erlaubnis in einer davon gewährt.
• Übermittlungen werden auch nach dem Namen der Anwendung entschieden. In jeder dieser Warteschlangen fragt der Agent auch nach der Warteschlange mit dem Namen der Anwendung, sodass eine Richtlinie nur einige Anwendungen, etwa payroll-*, in eine Warteschlange und die darunter zulassen kann.
• Richtlinien können nur für einige Netze gelten. Jede Prüfung trägt die Adresse des Clients, hinter einem Proxy die erste weitergeleitete, und der Agent wertet die Bedingung Client-Adressen mit Hadoops eigenen Hostlisten aus.
• Die Verwaltung des Clusters unterliegt Richtlinien. YARNs Verwaltungsoperationen, die sonst yarn.admin.acl gewährt, brauchen admin auf dem Cluster.
• Ablehnungen werden mit ihrem Grund protokolliert. YARN formuliert die Ablehnung, die der Client erhält; das Protokoll des ResourceManagers nennt die GrantForge-Richtlinie, die verweigert hat, oder dass keine es erlaubt.
• Entscheidungen werden behalten und Zugriffe zusammengefasst. Die Entscheidungen des aktuellen Snapshots werden behalten, standardmäßig 100.000 für 10 Sekunden, und ein neuer Snapshot beginnt von vorn. Gleiche erlaubte Zugriffe innerhalb eines Fensters, standardmäßig 10 Sekunden, werden als ein Zugriffsereignis gemeldet, das sagt, wie viele es waren; Ablehnungen werden einzeln und sofort gemeldet. Jedes Ereignis nennt Anwendung, Warteschlange und Client-Adresse.
• Der ResourceManager wird nicht geprüft. Der eigene Benutzer des ResourceManagers, etwa yarn, wird weder geprüft noch auditiert.

Bereitstellung

1. Fügen Sie einen yarn-Datendienst hinzu und konfigurieren Sie seine Richtlinien. Öffnen Sie Datenberechtigungen → Agenten, wählen Sie den Dienst und stellen Sie ein Agent-Token aus. Es wird nur einmal angezeigt; legen Sie es in einer Datei ab, die nur YARNs Konto lesen kann.

2. Kopieren Sie das JAR nach share/hadoop/yarn/lib jedes ResourceManagers, etwa /opt/hadoop/share/hadoop/yarn/lib.

3. Ergänzen Sie die Einstellungen in der yarn-site.xml jedes ResourceManagers und ersetzen Sie Beispieladresse, Pfade, Benutzer und Instanznamen:

   <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 darf nur den eigenen Benutzer des ResourceManagers nennen: YARN lässt seine Verwalter alles mit jeder Anwendung tun, bevor es den Agent nach der Warteschlange fragt. Das Cache-Verzeichnis muss für YARNs Konto beschreibbar sein.

4. Starten Sie die ResourceManager nacheinander neu. Bis der Agent seinen ersten Snapshot hat, werden Anfragen außer denen des ResourceManagers abgelehnt.

5. Vorhandene Berechtigungen zuerst übertragen: Die Warteschlangen-ACLs der Scheduler-Konfiguration, etwa acl_submit_applications und acl_administer_queue, gelten nicht mehr. Legen Sie vorher passende Richtlinien an.

Benutzer, Gruppen und Rollen

Richtlinien nennen den Kurznamen, den YARN dem Aufrufer gibt: den Benutzernamen der einfachen Authentifizierung oder den Kurznamen eines Kerberos-Prinzipals nach hadoop.security.auth_to_local. Gruppen sind die, die Hadoops Gruppenzuordnung dem Benutzer auf dem ResourceManager gibt, zusammen mit den Gruppen, in die GrantForge den Benutzer stellt; Rollen sind die, die GrantForge dem Benutzer gibt.

Entscheidungen und Grenzen

• Ohne verwendbaren Snapshot wird alles außer den eigenen Anfragen des ResourceManagers abgelehnt. Ein nicht verwendeter Dienst lässt YARN ungeprüft, wie mit ausgeschaltetem yarn.acl.enable.
• Ein Token, das an einen Dienst gebunden ist, dessen Typ nicht yarn ist, lehnt alles ab.
• YARN fragt nach seiner Verwaltung ohne die Adresse des Clients, daher gilt eine Bedingung Client-Adressen auf cluster nie.
• Der Eigentümer einer Anwendung und die Benutzer, die ihre eigenen ACLs nennen, verwalten sie unabhängig von den Richtlinien, wie in YARN.
• Prüfungen anderer Zugriffsarten, etwa ACLs für Anwendungsprioritäten, werden abgelehnt.
• Ein Hostname in einer Bedingung Client-Adressen kostet eine Namensauflösung des Clients, wann immer eine Entscheidung getroffen statt behalten wird.
• Entscheidungen werden für grantforge.decision.cache.ttl.ms behalten, daher beginnt oder endet die Gültigkeit einer Richtlinie bis zu so viel später.

Weitere Anleitungen

• Apache Hadoop YARN
• Datendienste, Richtlinien und Agenten