Apache Ranger vs. Apache Sentry
Management Summary
Bei großen Hadoop-Umgebungen ist die Verwaltung von einzelnen Zugriffsrechten aufwändig. Sowohl Sentry als auch Ranger sind eine Lösung, um solche Rechte zentral zu administrieren.
Beide Anwendungen haben eine unterschiedliche Vorgehensweise bei der Abbildung der zentral vergebenen Rechte in die einzelnen Programme.
Hierbei zeigt sich, dass die Architektur von Ranger deutlich flexibler ist und ferner deutlich mehr Anwendungen unterstützt.
Einführung
Bei der Bereitstellung großer Hadoop-Umgebungen fällt viel Verwaltungsaufwand an. Nutzerrechte müssen vergeben werden und gepflegt werden. Je nach Anzahl an genutzten Anwendungen wird dies zunehmend unübersichtlich. Neben dem hohen Aufwand gefährdet dies auch die Sicherheit der Architektur, da ein Überblick über die gewährten Rechte kaum möglich ist.
Hier sollen Apache Ranger und Apache Sentry eine Lösung anbieten. Beide Anwendungen wurden entwickelt, um eine zentrale Plattform bereitzustellen, mit der Nutzerrechte zentral vergeben und verwaltet werden können. Dort getroffene Entscheidungen werden dann in die von Ranger bzw. Sentry unterstützten Anwendungen auf Prozessebene eingebunden.
Apache Ranger startete als kommerzielles Produkt von XA Secure. Dieses Unternehmen wurde 2014 von Hortonworks übernommen und das Produkt als Apache Ranger als Open-Source-Produkt neu veröffentlicht.
Die Entwicklung von Apache Sentry startete 2012 als internes Projekt („Cloudera Access“) von Cloudera. 2013 erfolgte die Umbenennung in Sentry und die Aufnahme in den Apache Incubator.
Im Folgenden wird zunächst beschrieben, wie die Rechteprüfung durch die Anwendungen umgesetzt wird und wie das jeweilige Programm in den Hadoop-Stack eingebunden ist bzw. welche Projekte es unterstützt (4). Abschließend wird ein Fazit getroffen und eine Empfehlung gegeben (5).
Funktionalität
Allgemeines
Bei der Administration von Zugriffsrechten muss man folgende Termini voneinander unterscheiden:
- Ressource: Ein Objekt (bspw. ein Datensatz), dessen Zugriffsmöglichkeiten reguliert werden soll
- Nutzer: Ein individueller Nutzer
- Gruppe: Eine Sammlung an Nutzern. Normalerweise werden in Gruppen Nutzer mit gleichen Tätigkeiten zusammengefasst
- Privileg: Ein Recht eine bestimmte Tätigkeit ausführen zu dürfen
- Authentifizierung: Verifizierung der Nutzeridentität. ([icon name=”arrow-right” class=”” unprefixed_class=””] Anmeldesystem)
- Autorisierung: Verifizierung eines Privilegs – gestatten/verhindern eines Vorganges
- Rolle: Eine Sammlung an Privilegien.
Sowohl Ranger als auch Sentry thematisieren vor allem das Problem der Autorisierung von Nutzern. Hierzu können bei beiden Anwendungen Rollen definiert werden, um Privilegien einfacher zu verwalten.
Apache Ranger
Ranger vergibt Privilegien sowohl auf Gruppen- als auch auf Nutzerebene. Die Privilegien werden zentral im Admin Portal definiert und von Ranger Plugins evaluiert. Diese kleinen Plugins setzten auf den jeweiligen Master-Nodes auf (NameNode, Hive2Server, Nimbus, etc.) und laufen innerhalb des jeweiligen Master-Node-Prozesses. Hierdurch entstehen keine weiteren Kosten auf Betriebssystemebene. Die von Ranger verwalteten Privilegien sind unabhängig von nativen Privilegien.
Neben einer Ressourcen-basierten Privilegiendefinition können auch Privilegien basierend auf Markierungen („Tags“) vorgenommen werden, beispielsweise könnten Dateien markiert werden, die private Informationen enthalten mit der Folge, dass das zu dieser Markierung zugehörige Privileg forciert wird ohne, dass neue Privilegien für die Ressource erstellt werden müssen.
Apache Sentry
Sentry vergibt Privilegien – nur auf Gruppenebene – nicht auf dem individuellen Nutzerniveau, dabei können nur Rollen Gruppen zugeordnet werden. Weder können einzelne Privilegien direkt einer Gruppe zugeordnet werden noch können Rollen direkt einem einzelnen Nutzer zugeordnet sein. Ferner müssen die Gruppen als sekundäre Unix-Gruppen erzeugt werden.
Die Architektur Sentrys besteht aus drei Teilen:
- Sentry Server: verwaltet die Sentry-Metadaten
- Data Engine: Datenprozessor (Hive oder Impala), der das Sentry-Plugin ausführt, so dass alle Abfragen abgefangen und über das Plugin umgeleitet werden
- Sentry Plugin: Programm, welches innerhalb der Data Engine läuft. Evaluiert, ob die gewünschten Datenzugriffe für den jeweiligen Benutzer erfolgen dürfen oder nicht.
Vergleich Ranger vs. Sentry: Funktionalität
Vergleicht man beide Anwendungen, so fällt auf, dass Ranger deutlich flexibler als Sentry die Berechtigungen verwalten kann:
- Bei Ranger müssen keine sekundäre Unix-Gruppen erzeugt werden, um Gruppen einrichten zu können
- Ranger ist generell unabhängig von nativen Berechtigungssystemen, kann diese aber zusätzlich aktivieren, bspw. HDFS-Privilegien prüfen, wenn die Anfrage bisher nicht über das Ranger-Berechtigungssystem abgebildet wurde
- Sentry verdeckt die nativen Berechtigungssysteme.
- Bei Ranger können neben Gruppen auch individuellen Nutzern Privilegien zugeordnet werden
- Neben dem ressourcenbasierten Berechtigungssystem bietet Ranger auch ein Berechtigungssystem basierend auf Markierungen („Tags“) an
- Die Autorisierungsprozesse von Ranger finden im Prozess der jeweiligen Master-Node statt, dadurch werden die dort getroffenen Replikationseinstellungen automatisch übernommen
- Ranger ist nicht auf eine Data Engine angewiesen, um den Nutzernamen zu bestimmen und unterstützt somit deutlich mehr Anwendungen als Sentry.
Einbindung in Hadoop-Architektur
Apache Ranger
Apache Ranger unterstützt die Rechteverwaltung von:
- Apache Hadoop
- Apache Hive
- Apache HBase
- Apache Storm
- Apache Knox
- Apache Solr
- Apache Kafka
- Apache NiFi
- YARN
Apache Sentry
Apache Sentry unterstützt die Rechteverwaltung von:
- Impala
- Hive
- HDFS
- Solr
Hierbei sind jedoch folgende Punkte zu beachten:
- HDFS-Privilegien können nur für Daten vergeben werden, die zu einem Hive Warehouse gehören – also Teil einer Hive- oder Impala-Tabelle sind
- Wenn HDFS-Privilegien durch Sentry verwaltet werden, können keine eigenen Änderungen an den nativen HDFS-Berechtigungen vorgenommen werden
- Wenn die HDFS ACL eines von Sentry verwalteten Objektes direkt angepasst werden, wird keine Änderung übernommen, da die Verwaltung nur durch Sentry ermöglicht wird.
- Die Funktion Synchronisierung bedeutet hierbei nur eine unidirektionale Richtung. Nur Änderungen, die in Sentry vorgenommen werden, werden in den HDFS-Berechtigungen abgebildet
- Tabellen, die nicht von Sentry verwaltet werden, behalten ihre eigenen ACLs bei.
- Liegen die HDFS-Daten außerhalb des Standard-Hive-Pfades, so muss dies explizit konfiguriert werden
- HDFS-Privilegien werden nicht im HDFS persistiert (bspw. durch Speicherung in HDFS ACLs), d.h. wenn Sentry deaktiviert wird, werden die Berechtigungen wieder auf ihren ursprünglichen Zustand zurückgeschickt
- Wenn die Verwaltung durch Sentry aktiviert wird, bekommt der Hive-Nutzer bzw. die Hive-Nutzergruppe automatisch Besitzrechte über alle im Hive Warehouse befindlichen Pfade und Dateien
- Verliert die NameNode den Kontakt mit dem Sentry Server über eine längere Zeit, werden alle Berechtigungen für die von Sentry verwalteten Pfade (unabhängig davon, ob die spezifischen Objekte zu einem Hive Warehouse gehören) auf den Hive-Systemnutzer bzw. die Hive-Systemgruppe gesetzt
- Keine spaltengenaue Zugriffskontrolle für Spark SQL möglich
- Das Sentry-Plugin für Solr unterstützt noch nicht die datenbankbasierte Rechteverwaltung, sondern nur die dateibasierte Rechteverwaltung
- Wenn Hive durch Sentry verwaltet werden soll, muss der Zugriff der Hive CLI auf dem Hive Metastore ausgeschaltet werden.
Vergleich Ranger vs. Sentry: Integration in Hadoop-Stack
Im Vergleich fällt auf, dass:
- Ranger deutlich mehr Anwendungen als Sentry unterstützt
- Sentry bei der Verwaltung von HDFS-Privilegien viele Einschränkungen hat, die es zu beachten gilt
- Bedingt durch die in (3.4) beschriebenen Architekturnachteile durch das Benötigen einer Data Engine
- Einschränkung auf Daten im Hive-Warehouse
- Spark wird von Sentry nicht vollständig unterstützt
- Ranger hat im Vergleich zu Sentry noch weitere Funktionen wie eine Schlüsselverwaltung und eine Echtzeit-Audit-Möglichkeit
- Ranger stimmt seine Entwicklung mit weiteren Apache-Projekten wie Atlas und Ambari ab.
Fazit
Sowohl mit Ranger als auch mit Sentry können Nutzerrechte in Hadoop-Architekturen zentral verwaltet werden. Entsprechend sollte die Entscheidung für oder gegen Ranger bzw. Sentry nicht davon abhängig gemacht werden, sondern insbesondere von den von ihnen unterstützten Anwendungen. Hier zeigt sich auch der Entstehungshintergrund der beiden Programme. Während Ranger insbesondere viele Anwendungen aus dem Bereich der Hortonworks Hadoop Data Platform unterstützt, unterstützt Sentry eher Anwendungen der Cloudera CDH Plattform. Folgerichtig ist für ein ein bestehendes Projekt auf Cloudera CDH Sentry die nähere Wahl.
Eine generelle Übersicht über die beiden populären Hadoop-Distributionen findet sich hier.
Beim Vergleich von Ranger und Sentry untereinander ist Ranger das deutlich ausgereiftere System.So unterstützt Ranger deutlich mehr Anwendungen als Sentry und bietet eine eigene grafische Oberfläche für die Administration. Zudem bindet sich die Architektur von Ranger deutlich besser in andere Anwendungen ein als Sentry. Dies zeigt sich beispielsweise in der Administration von HDFS-Berechtigungen: Während Ranger die Hadoop NameNode hierzu nutzt, ist Sentry darauf angewiesen, dass die Daten generell von Hive verwaltet werden bzw. in einem Hive-Warehouse liegen.
