Kerberisierter Data Lake in Dataproc

Last reviewed 2024-04-16 UTC

Dieses Dokument erläutert die Konzepte, Best Practices und Referenzarchitekturen für das Netzwerk, die Authentifizierung und Autorisierung eines kerberisierten Data Lake in Google Cloud mithilfe des von Dataproc bereitgestellten clustereigenen Key Distribution Center (KDC) und von Apache Ranger Dataproc ist der verwaltete Hadoop- und Spark-Dienst von Google Cloud. Dieses Dokument richtet sich an Apache Hadoop-Administratoren, Cloud-Architekten und Big-Data-Teams, die ihre traditionellen Hadoop- und Spark-Cluster zu einem modernen, von Dataproc bereitgestellten Data Lake migrieren.

Ein kerberisierter Data Lake in Google Cloud unterstützt Unternehmen mit Hybrid- und Multi-Cloud-Bereitstellungen dabei, ihre vorhandenen IT-Investitionen in die Verwaltung von Identitäts- und Zugriffssteuerung zu erweitern und zu verwenden.

In Google Cloud können Unternehmen ihren Teams so viele sitzungsspezifische Cluster bereitstellen, wie erforderlich. Dieser Ansatz reduziert die Komplexitäten bei der Verwaltung eines einzelnen Clusters mit den zunehmenden Abhängigkeiten und Interaktionen der unterschiedlichen Softwarekonfigurationen. Unternehmen können auch länger laufende Cluster erstellen, auf die mehrere Nutzer und Dienste zugreifen können. In diesem Dokument wird gezeigt, wie Sie branchenübliche Standardtools wie Kerberos und Apache Ranger dazu nutzen können, in beiden Cluster-Dataproc-Umgebungen eine detaillierte Nutzersicherheit (Authentifizierung, Autorisierung und Auditing) zu gewährleisten.

Kundenanwendungsfall

Unternehmen migrieren ihre lokalen Hadoop-basierten Data Lakes zu öffentlichen Cloud-Plattformen, um die Herausforderungen zu bewältigen, mit denen ihre traditionellen Cluster konfrontiert sind.

Eines dieser Unternehmen, ein führender Technologieanbieter im Bereich Enterprise-Software und -Hardware, beschloss, sein lokales Hadoop-System zu Google Cloud zu migrieren. Die lokale Hadoop-Umgebung war für die Analyseanforderungen von Hunderten von Teams und Geschäftseinheiten zuständig, darunter das Cybersicherheitsteam, das 200 Mitglieder von Datenanalyseteams umfasste. Wenn ein Teammitglied eine große Abfrage mit dem alten Data Lake ausgeführt hat, gab es Probleme aufgrund der starren Natur seiner Ressourcen. Für das Unternehmen wurde es zunehmend schwierig, die Analyseanforderungen des Teams in der lokalen Umgebung zu erfüllen. Daher wechselte es zu Google Cloud. Durch den Wechsel zu Google Cloud konnte das Unternehmen die Anzahl der in seinem lokalen Data Lake gemeldeten Probleme um 25% pro Monat reduzieren.

Die Grundlage für den Migrationsplan des Unternehmens zu Google Cloud bestand in der Entscheidung, die monolithischen Cluster nach den Arbeitslasten der Teams umzuformen und zu optimieren und den Fokus von der Clusterverwaltung auf die Wertschöpfung zu verschieben. Die wenigen großen Cluster wurden in kleinere, kostengünstige Dataproc-Cluster aufgeteilt, während Arbeitslasten und Teams zu den folgenden Modelltypen migriert wurden:

  • Sitzungsspezifische jobbezogene Cluster: Mit nur wenigen Minuten Hochverfügbarkeitszeit erlaubt das sitzungsspezifische Modell einem Job oder einem Workflow einen dedizierten Cluster zu nutzen, der nach Abschluss des Jobs heruntergefahren wird. Bei diesem Modell wird der Speicher von Computing-Knoten entkoppelt. Dabei wird das Hadoop Distributed File System (HDFS) durch Cloud Storage ersetzt. Dies geschieht durch den in Dataproc integrierten Cloud Storage Connector für Hadoop.
  • Cluster mit halblanger Ausführungszeit: Wenn sitzungsspezifische jobbezogene Cluster den Anwendungsfall nicht verarbeiten können, können Dataproc-Cluster lange ausgeführt werden. Wenn die zustandsorientierten Daten des Clusters an Cloud Storage übertragen werden, kann der Cluster einfach heruntergefahren werden und sie gelten als halb lang ausgeführt. Mit dem smarten Cluster-Autoscaling können diese Cluster auch klein gestartet und ihre Computing-Ressourcen für bestimmte Anwendungen optimiert werden. Dieses Autoscaling ersetzt die Verwaltung von YARN-Warteschlangen.

Die Herausforderung für Hybridsicherheit

Im obigen Kundenszenario hat der Kunde sein umfangreiches Datenverwaltungssystem in die Cloud migriert. Andere Teile der IT-Abteilung des Unternehmens mussten jedoch lokal bleiben (z. B. einige Legacy-Betriebssysteme, die den Data Lake speisen).

Es war eine Sicherheitsarchitektur erforderlich, die sicherstellte, dass der lokale zentrale LDAP-basierte Identitätsanbieter (IdP) die autoritative Quelle für die Unternehmensidentitäten blieb, die den Data Lake verwenden. Die lokale Hadoop-Sicherheit basiert auf Kerberos und LDAP zur Authentifizierung (häufig als Teil des Microsoft Active Directory (AD)) des Unternehmens und auf mehreren anderen Open-Source-Software-Produkten wie Apache Ranger. Dieser Sicherheitsansatz ermöglicht eine differenzierte Autorisierung und Prüfung der Aktivitäten von Nutzern und Teams in den Data-Lake-Clustern. In Google Cloud wird die Identitäts- und Zugriffsverwaltung (IAM) verwendet, um den Zugriff auf bestimmte Google Cloud-Ressourcen wie Dataproc und Cloud Storage zu verwalten.

In diesem Dokument wird ein Sicherheitsansatz erläutert, der das Beste aus lokaler und OSS-Hadoop-Sicherheit verwendet (Schwerpunkt auf Kerberos, Unternehmens-LDAP und Apache Ranger) sowie IAM, um Arbeitslasten und Daten innerhalb und außerhalb der Hadoop-Cluster zu schützen.

Architektur

Im folgenden Diagramm ist die allgemeine Architektur dargestellt:

Allgemeine Architektur eines kerberisierten Data Lake in Google Cloud mit Dataproc.

Im obigen Diagramm führen Clients Jobs auf Multi-Team- oder Einzel-Cluster-Clustern aus. Die Cluster verwenden einen zentralen Hive-Metastore und eine Kerberos-Authentifizierung mit einem Unternehmensidentitätsanbieter.

Komponenten

Die Architektur schlägt eine Kombination aus Branchenstandard-Open-Source-Tools und IAM vor, um die verschiedenen Möglichkeiten zum Senden von Jobs zu authentifizieren und zu autorisieren, die weiter unten in diesem Dokument beschrieben werden. Im Folgenden finden Sie die Hauptkomponenten, die gemeinsam für die Sicherheit von Team- und Nutzerarbeitslasten in den Hadoop-Clustern sorgen:

  • Kerberos: Kerberos ist ein Netzwerkauthentifizierungsprotokoll, das eine Secret-Schlüssel-Kryptografie verwendet, um eine starke Authentifizierung für Client-/Serveranwendungen zu ermöglichen. Der Kerberos-Server wird als Key Distribution Center (KDC) bezeichnet.

    Kerberos wird in lokalen Systemen wie Active Directory häufig verwendet, um menschliche Nutzer, Dienste und Computer zu authentifizieren. Cliententitäten werden als Benutzerprinzipale bezeichnet. Bei der Aktivierung von Kerberos in Dataproc wird die kostenlose MIT-Distribution von Kerberos verwendet, um ein clustereigenes KDC zu erstellen. Das clustereigene KDC von Dataproc dient den Anfragen von Nutzerprinzipalen als Zugriffsressource innerhalb des Clusters, z. B. Apache Hadoop YARN, HDFS und Apache Spark. Serverressourcen werden als Dienstprinzipale bezeichnet. Mit der bereichsübergreifenden Vertrauensstellung von Kerberos können Sie die Nutzerprinzipale eines Bereichs mit einem anderen verbinden.

  • Apache Ranger: Apache Ranger bietet eine differenzierte Autorisierung für Nutzer, um bestimmte Aktionen für Hadoop-Dienste auszuführen. Es prüft außerdem den Nutzerzugriff und implementiert administrative Maßnahmen. Ranger kann mit einem lokalen Unternehmens-LDAP-Server oder mit AD synchronisiert werden, um Nutzer- und Dienstidentitäten abzurufen.

  • Gemeinsam genutzter Hive-Metastore: Der Hive-Metastore ist ein Dienst, in dem Metadaten für Apache Hive und andere Hadoop-Tools gespeichert werden. Da viele dieser Tools um sie herum erstellt wurden, ist der Hive-Metastore zu einem wichtigen Bestandteil vieler Data Lakes geworden. In der vorgeschlagenen Architektur ermöglicht ein zentralisierter und kerberisierter Hive-Metastore, dass mehrere Cluster Metadaten sicher gemeinsam nutzen können.

Während Kerberos, Ranger und ein freigegebener Hive-Metastore zusammenwirken, um eine detailgenaue Nutzersicherheit innerhalb der Hadoop-Cluster zu ermöglichen, steuert IAM den Zugriff auf Google Cloud-Ressourcen. Dataproc verwendet beispielsweise das Dataproc-Dienstkonto, um Lese- und Schreibvorgänge in Cloud Storage-Buckets durchzuführen.

Aspekte eines Clusters

Die folgenden Aspekte beschreiben einen Dataproc-Cluster:

  • Mandantenfähigkeit: Ein Cluster ist mehrmandantenfähig, wenn er die Anfragen von mehr als einem Nutzer oder Dienst verarbeitet, oder er ist einzelmandantenfähig, wenn er die Anfragen eines einzelnen Nutzers oder Dienstes verarbeitet.
  • Kerberos Ein Cluster kann kerberisiert sein, wenn Sie Kerberos in Dataproc aktivieren oder er kann nicht-kerberisiert sein, wenn Sie Kerberos in Dataproc nicht aktivieren.
  • Lebenszyklus: Ein Cluster ist sitzungsspezifisch, wenn er nur für die Dauer eines bestimmten Jobs oder Workflows erstellt wurde, wenn er nur die zum Ausführen des Jobs erforderlichen Ressourcen enthält und wenn er nach Abschluss des Jobs heruntergefahren wird. Andernfalls gilt der Cluster als halblang ausgeführt.

Unterschiedliche Kombinationen dieser Aspekte bestimmen die Anwendungsfälle, für die ein bestimmter Cluster am besten geeignet ist. In diesem Dokument werden die folgenden repräsentativen Beispiele erläutert:

  1. Die im Architekturdiagramm gezeigten Multi-Team-Cluster sind beispielhafte Cluster mit mehreren Mandanten und halblanger Ausführungszeit. Diese Cluster eignen sich am besten für interaktive Abfragearbeitslasten, z. B. für Langzeitdatenanalysen und BI-Erkundungen (Business Intelligence). In der Beispielarchitektur befinden sich die Cluster in einem Google Cloud-Projekt, das von mehreren Teams gemeinsam genutzt wird und die Anfragen dieser Teams bedient. Daher der Name.

    In diesem Dokument bezeichnet der Begriff Team oder Anwendungsteam eine Gruppe von Personen in einem Unternehmen, die an derselben Softwarekomponente arbeiten oder als funktionales Team arbeiten. Ein Team kann sich beispielsweise auf Back-End-Entwickler eines Mikrodiensts, BI-Analysten einer Geschäftsanwendung oder sogar funktionsübergreifende Teams wie Big-Data-Infrastrukturteams beziehen.

  2. Die in der Beispielarchitektur gezeigten Einzel-Team-Cluster sind Cluster, die mehrmandantenfähig (für Mitglieder desselben Teams) oder einzelmandantenfähig sein können.

  • Als sitzungsspezifische Cluster können Einzel-Team-Cluster für bestimmte Jobs verwendet werden, zum Beispiel von Data Engineers beim Ausführen von Spark-Batchverarbeitungsjobs oder von Data Scientists beim Ausführen von Modelltrainingsjobs.

  • Als Cluster mit halblanger Ausführungszeit können Einzel-Team-Cluster Datenanalysen und BI-Arbeitslasten verarbeiten, die auf ein einzelnes Team oder eine einzelne Person beschränkt sind.

    Die Einzel-Team-Cluster befinden sich in Google Cloud-Projekten, die zu einem einzelnen Team gehören, was die Nutzungsprüfung, Abrechnung und Ressourcenisolation vereinfacht. Beispielsweise können nur Mitglieder des einzelnen Teams auf die Cloud Storage-Buckets zugreifen, die zur Speicherung der Clusterdaten verwendet werden. Bei diesem Ansatz haben Anwendungsteams dedizierte Projekte, sodass die Einzel-Team-Cluster nicht kerberisiert werden.

Wir empfehlen Ihnen, Ihre spezifischen Anforderungen zu analysieren und die besten Kombinationen der einzelnen Aspekte für Ihre Situation auszuwählen.

Jobs senden

Nutzer können mit verschiedenen Tools Jobs an beide Cluster senden, darunter:

  • Die Dataproc API mit REST-Aufrufen oder Clientbibliotheken.
  • Das gcloud-Befehlszeilentool der Google Cloud CLI in einem lokalen Terminalfenster oder über die Google Cloud Console in Cloud Shell, das in einem lokalen Browser geöffnet wird.
  • Eine Dataproc-Workflow-Vorlage, also eine wiederverwendbare Workflow-Konfiguration, die einen Graph von Jobs definiert, der Informationen dazu enthält, wo diese Jobs ausgeführt werden sollen. Wenn der Workflow die Option Verwalteter Cluster verwendet, wird ein sitzungsspezifischer Cluster verwendet.
  • Cloud Composer mit dem Dataproc-Operator. Composer-gerichtete azyklische Graphen (Directed Acyclic Graphs, DAGs) können auch zur Orchestrierung von Dataproc-Workflow-Vorlagen verwendet werden.
  • Öffnen einer SSH-Sitzung auf dem Masterknoten im Cluster und Senden eines Jobs direkt oder mithilfe von Tools wie Apache Beeline. Dieses Tool ist normalerweise nur für Administratoren und Poweruser reserviert. Ein Beispiel für einen Poweruser ist ein Entwickler, der Fehler in den Konfigurationsparametern für einen Dienst beheben und diese durch direkte Ausführung von Testjobs auf dem Masterknoten prüfen möchte.

Netzwerk

Das folgende Diagramm zeigt die Netzwerkkonzepte der Architektur:

Eine Netzwerkarchitektur mit einem Hybrid-Mesh-Muster.

Im obigen Diagramm verwendet die Netzwerkarchitektur ein Mesh-Hybridmuster, bei dem sich einige Ressourcen in Google Cloud und andere lokal befinden. Das Mesh-Hybridmuster verwendet eine freigegebene VPC mit einem gemeinsamen Hostprojekt und separaten Projekten für jeden Dataproc-Clustertyp und jedes Team. Die Architektur wird in den folgenden Abschnitten Mit Google Cloud und Lokal ausführlich beschrieben.

Innerhalb von Google Cloud

In Google Cloud wird die Architektur mithilfe einer freigegebenen VPC strukturiert. Über eine freigegebene VPC können Ressourcen aus mehreren Projekten eine Verbindung zu einem gemeinsamen VPC-Netzwerk herstellen. Über ein gemeinsames VPC-Netzwerk können Ressourcen sicher und effizient über interne IP-Adressen dieses Netzwerks miteinander kommunizieren. Erstellen Sie die folgenden Projekte, um eine freigegebene VPC einzurichten:

  • Hostprojekt: Das Hostprojekt enthält ein oder mehrere freigegebene VPC-Netzwerke, die von allen Dienstprojekten verwendet werden.

  • Dienstprojekte: Ein Dienstprojekt enthält zugehörige Google Cloud-Ressourcen. Ein Administrator für freigegebene VPC hängt die Dienstprojekte an das Hostprojekt an, damit er Subnetze und Ressourcen im freigegebenen VPC-Netzwerk verwenden kann. Dieser Anhang ist wichtig, damit die Einzel-Team-Cluster auf den zentralen Hive-Metastore zugreifen können.

    Wie im Netzwerk-Diagramm gezeigt, empfehlen wir, separate Dienstprojekte für den Hive-Metastore-Cluster, die Multi-Team-Cluster und die Cluster für jedes einzelne Team zu erstellen. Die Mitglieder jedes Teams in Ihrem Unternehmen können dann Einzel-Team-Cluster in den jeweiligen Projekten erstellen.

Damit die Komponenten im Hybridnetzwerk miteinander kommunizieren können, müssen Sie Firewallregeln so konfigurieren, dass der folgende Traffic zulässig ist:

  • Interner Clustertraffic für Hadoop-Dienste, einschließlich HDFS NameNode, um mit HDFS DataNodes zu kommunizieren, und YARN ResourceManager für die Kommunikation mit YARN NodeManagers. Wir empfehlen, für diese Regeln die Filterung mit dem Cluster-Dienstkonto zu verwenden.
  • Externer Cluster-Traffic an bestimmten Ports zur Kommunikation mit dem Hive-Metastore (Port tcp:9083,8020), dem lokalen KDC (Port tcp:88) und LDAP (Port 636) sowie anderen zentralisierten externen Diensten, die Sie in Ihrem speziellen Szenario verwenden, z. B. Kafka in Google Kubernetes Engine (GKE).

Alle Dataproc-Cluster in dieser Architektur werden nur mit internen IP-Adressen erstellt. Damit Clusterknoten Zugriff auf Google APIs und Google-Dienste haben, müssen Sie für die Cluster-Subnetze den privaten Google-Zugriff aktivieren. Damit Administratoren und Poweruser auf die VM-Instanzen der privaten IP-Adresse zugreifen können, verwenden Sie die IAP-TCP-Weiterleitung, um SSH-, RDP- und anderen Traffic über einen verschlüsselten Tunnel weiterzuleiten.

Ein sicherer Zugriff auf die Cluster-Weboberflächen der Clusteranwendungen und optionalen Komponenten (z. B. Spark, Hadoop, Jupyter und Zeppelin) erfolgt über das Dataproc Component Gateway. Das Dataproc Component Gateway ist ein HTTP-umgekehrter Proxy, der auf Apache Knox basiert.

Lokal

In diesem Dokument wird davon ausgegangen, dass sich die lokalen Ressourcen im LDAP-Verzeichnisdienst des Unternehmens und im Kerberos-Key Distribution Center (KDC) befinden, in dem die Nutzer- und Teamdienstprinzipale definiert sind. Wenn Sie keinen lokalen Identitätsanbieter verwenden müssen, können Sie eine einfache Einrichtung mit Cloud Identity und einem KDC in einem Dataproc-Cluster oder in einer virtuellen Maschine vornehmen.

Für die Kommunikation mit dem lokalen LDAP und KDC verwenden Sie entweder Cloud Interconnect oder Cloud VPN. Dadurch wird gewährleistet, dass die Kommunikation zwischen Umgebungen private IP-Adressen verwendet, wenn sich die Subnetzwerke in der IP-Adresse nach RFC 1918 nicht überschneiden. Weitere Informationen zu den verschiedenen Verbindungsoptionen finden Sie unter Netzwerkverbindungsprodukt auswählen.

In einem Hybridszenario müssen Ihre Authentifizierungsanfragen mit minimaler Latenz verarbeitet werden. Dazu können Sie folgende Methoden verwenden:

  • Lassen Sie alle Authentifizierungsanfragen für Dienstidentitäten im clustereigenen KDC verarbeiten und verwenden Sie nur dann einen Identitätsanbieter außerhalb des Clusters, wenn Nutzeridentitäten authentifiziert werden sollen. Der Großteil des Authentifizierungstraffics wird voraussichtlich von Dienstidentitätsanfragen stammen.
  • Wenn Sie Active Directory als Identitätsanbieter verwenden, stellen die Nutzerprinzipalnamen (UPNs) die menschlichen Nutzer und die AD-Dienstkonten dar. Es empfiehlt sich, die UPNs von Ihrem lokalen AD in einer Google Cloud-Region zu replizieren, die sich in der Nähe Ihrer Data-Lake-Cluster befindet. Dieses AD-Replikat verarbeitet Authentifizierungsanfragen für UPNs. Daher werden die Anfragen nie an Ihr lokales AD übertragen. Jeder KDC im Cluster verarbeitet die Dienstprinzipalnamen (SPNs) mit der ersten Methode.

Das folgende Diagramm zeigt eine Architektur, in der beide Techniken genutzt werden:

Das lokale AD synchronisiert UPNs mit einem AD-Replikat, während ein clustereigenes KDC die SPNs authentifiziert.

Im vorherigen Diagramm synchronisiert ein lokales AD die UPNs mit einem AD-Replikat in einer Google Cloud-Region. Das AD-Replikat authentifiziert die UPNs und das clustereigene KDC authentifiziert die SPNs.

Informationen zum Bereitstellen von AD in Google Cloud finden Sie unter Fehlertolerante Microsoft Active Directory-Umgebung bereitstellen. Informationen dazu, wie die Anzahl der Instanzen für Domaincontroller angepasst werden kann, finden Sie unter MIT Kerberos und Active Directory integrieren.

Authentifizierung

Das folgende Diagramm zeigt die Komponenten, mit denen Nutzer in verschiedenen Hadoop-Clustern authentifiziert werden. Mit der Authentifizierung können Nutzer Dienste wie Apache Hive oder Apache Spark verwenden.

Komponenten authentifizieren Nutzer in verschiedenen Hadoop-Clustern.

Im vorherigen Diagramm können Cluster in Kerberos-Bereichen die bereichsübergreifende Vertrauensstellung einrichten, um Dienste auf anderen Clustern wie dem Hive-Metastore zu verwenden. Nicht-kerberisierte Cluster können einen Kerberos-Client und einen Konto-Keytab verwenden, um Dienste in anderen Clustern zu verwenden.

Freigegebener und gesicherter Hive-Metastore

Der zentralisierte Hive-Metastore ermöglicht die gemeinsame Nutzung mehrerer Cluster, die unterschiedliche Open-Source-Abfrage-Engines wie Apache Spark, Apache Hive/Beeline und Presto ausführen, um Metadaten freizugeben.

Sie stellen den Hive-Metastore-Server in einem kerberisierten Dataproc-Cluster bereit und stellen die Hive-Metastore-Datenbank auf einem Remote-RDBMS, z. B. einer MySQL-Instanz in Cloud SQL, bereit. Als freigegebener Dienst verarbeitet ein Hive-Metastore-Cluster nur authentifizierte Anfragen. Weitere Informationen zum Konfigurieren des Hive-Metastores finden Sie unter Apache Hive in Dataproc verwenden.

Anstelle des Hive-Metastores können Sie den Dataproc Metastore verwenden, der ein vollständig verwalteter, hochverfügbarer (innerhalb einer Region), automatisch reparierender, serverloser Apache Hive-Metastore ist. Sie können Kerberos auch für den Dataproc Metastore-Dienst aktivieren, wie unter Kerberos für einen Dienst konfigurieren beschrieben.

Kerberos

In dieser Architektur werden die Multi-Team-Cluster für Analysezwecke verwendet und gemäß der Anleitung zur Dataproc-Sicherheitskonfiguration kerberisiert. Der sichere Dataproc-Modus erstellt ein clustereigenes KDC und verwaltet die Dienstprinzipale und Keytabs des Clusters, wie dies die Spezifikation des sicheren Modus von Hadoop erfordert.

Ein Keytab ist eine Datei, die ein oder mehrere Kerberos-Prinzipale und eine verschlüsselte Kopie des Prinzipalschlüssels enthält. Ein Keytab ermöglicht die programmatische Kerberos-Authentifizierung, wenn die interaktive Anmeldung mit dem Befehl kinit nicht möglich ist.

Der Zugriff auf einen Keytab bedeutet, dass die darin enthaltenen Identitäten der Prinzipale übernommen werden können. Ein Keytab ist daher eine sehr sensible Datei, die sicher übertragen und gespeichert werden muss. Wir empfehlen die Verwendung von Secret Manager zum Speichern des Inhalts der Keytabs, bevor diese in ihre jeweiligen Cluster übertragen werden. Ein Beispiel für die Speicherung des Inhalts eines Keytabs finden Sie unter Kerberos für einen Dienst konfigurieren. Nachdem ein Keytab auf den Clustermasterknoten heruntergeladen wurde, muss die Datei eingeschränkte Dateizugriffsberechtigungen haben.

Das clustereigene KDC verarbeitet die Authentifizierungsanfragen für alle Dienste innerhalb dieses Clusters. Der Großteil der Authentifizierungsanfragen wird voraussichtlich dieser Typ von Anfragen sein. Damit die Latenz minimiert wird, muss das KDC diese Anfragen auflösen, ohne dass sie den Cluster verlassen.

Die verbleibenden Anfragen stammen von menschlichen Nutzern und AD-Dienstkonten. Das AD-Replikat in Google Cloud oder der lokale zentrale ID-Anbieter verarbeitet diese Anfragen, wie im vorherigen Abschnitt Lokal erläutert.

Bei dieser Architektur werden die Einzel-Team-Cluster nicht kerberisiert, sodass kein KDC vorhanden ist. Damit diese Cluster auf den freigegebenen Hive-Metastore zugreifen können, müssen Sie nur einen Kerberos-Client installieren. Wenn Sie den Zugriff automatisieren möchten, können Sie den Keytab des Teams verwenden. Weitere Informationen finden Sie im Abschnitt Identitätszuordnung weiter unten in diesem Dokument.

Kerberos-bereichsübergreifende Vertrauensstellung in Multi-Team-Clustern

Die bereichsübergreifende Vertrauensstellung ist hochgradig relevant, wenn Ihre Arbeitslasten Hybrid oder Multi-Cloud sind. Mit der bereichsübergreifenden Vertrauensstellung können Sie zentrale Unternehmensidentitäten in freigegebene Dienste einbinden, die in Ihrem Google Cloud Data Lake verfügbar sind.

In Kerberos definiert ein Bereich eine Gruppe von Systemen unter einem gemeinsamen KDC. Die bereichsübergreifende Authentifizierung ermöglicht es einem Nutzerprinzipal eines Bereichs, sich in einem anderen Bereich zu authentifizieren und dessen Dienste zu verwenden. Für diese Konfiguration müssen Sie das Vertrauen zwischen Bereichen herstellen.

In der Architektur gibt es drei Bereiche:

  • EXAMPLE.COM: ist der Unternehmensbereich, in dem alle Kerberos-Nutzerprinzipale für Nutzer, Teams und Dienste (UPNs) definiert sind.
  • MULTI.EXAMPLE.COM: ist der Bereich, der die Multi-Team-Cluster enthält. Der Cluster ist mit Dienstprinzipalen (SPNs) für die Hadoop-Dienste wie Apache Spark und Apache Hive vorkonfiguriert.
  • METASTORE.EXAMPLE.COM: ist ein Bereich für den Hive-Metastore.

Die Einzel-Team-Cluster sind nicht kerberisiert, sodass sie keinem Bereich angehören.

Damit Sie die zum Unternehmen gehörenden Nutzerprinzipale auf allen Clustern verwenden können, müssen Sie die folgenden unidirektionalen, bereichsübergreifenden Vertrauensstellungen einrichten:

  • Konfigurieren Sie den Multi-Team-Bereich und den Metastore-Bereich, sodass sie dem Unternehmensbereich vertrauen. Mit dieser Konfiguration können die Prinzipale, die im Unternehmensbereich definiert sind, auf die Multi-Team-Cluster und den Metastore zugreifen.

    Obwohl Vertrauen transitiv sein kann, empfehlen wir, den Metastore-Bereich so zu konfigurieren, dass er einer direkten Vertrauensstellung zum Unternehmensbereich entspricht. Diese Konfiguration hängt von der Verfügbarkeit des Multi-Team-Bereichs ab.

  • Konfigurieren Sie den Metastore so, dass er dem Multi-Team-Bereich vertraut, damit die Multi-Team-Cluster auf den Metastore zugreifen können. Diese Konfiguration ist erforderlich, um dem Hive-Server2-Prinzipal den Zugriff auf den Metastore zu gewähren.

Weitere Informationen finden Sie unter Erste Schritte mit Kerberos-Dataproc-Clustern mit bereichsübergreifender Vertrauensstellung und in den entsprechenden Terraform-Konfigurationsdateien im GitHub-Repository.

Wenn Sie einen integrierten oder cloudnativen IAM-Ansatz für Multi-Team-Cluster bevorzugen und wenn Sie keine Hybrididentitätsverwaltung benötigen, sollten Sie die Verwendung der Dataproc-dienstkontobasierten, sicheren Mehrmandantenfähigkeit in Betracht ziehen. In diesen Clustern können mehrere IAM-Identitäten als unterschiedliche Dienstkonten auf Cloud Storage und andere Google-Ressourcen zugreifen.

Identitätszuordnung in Einzel-Team-Clustern

In den vorherigen Abschnitten wurde die Konfiguration der kerberisierten Seite der Architektur beschrieben. Einzel-Team-Cluster sind jedoch nicht kerberisiert, sodass sie eine spezielle Methode erfordern, damit sie an dieser Systemumgebung teilnehmen können. Diese Methode verwendet das Attribut zur Trennung von Google Cloud-Projekten und IAM-Dienstkonten, um die Hadoop-Arbeitslasten von Anwendungsteams zu isolieren und zu sichern.

Wie im vorherigen Abschnitt Netzwerk beschrieben, hat jedes Team ein entsprechendes Google Cloud-Projekt, in dem es Einzel-Team-Cluster erstellen kann. Innerhalb der Einzel-Team-Cluster sind ein oder mehrere Mitglieder des Teams Mandanten des Clusters. Diese Methode der Projekttrennung beschränkt den Zugriff auf die von diesen Clustern verwendeten Cloud Storage-Buckets auf die jeweiligen Teams.

Ein Administrator erstellt das Dienstprojekt und stellt das Teamdienstkonto in diesem Projekt bereit. Beim Erstellen eines Clusters wird dieses Dienstkonto als Clusterdienstkonto angegeben.

Der Administrator erstellt auch einen Kerberos-Prinzipal für das Team im Unternehmensbereich und den entsprechenden Keytab. Der Keytab wird sicher im Secret Manager gespeichert und der Administrator kopiert den Keytab in den Masterknoten des Clusters. Der Kerberos-Prinzipal ermöglicht den Zugriff vom Einzel-Team-Cluster auf den Hive-Metastore.

Für eine automatisierte Bereitstellung und für eine einfache Erkennung dieser Paare verwandter Identitäten sollten die Identitäten einer gemeinsamen Namenskonvention folgen. Beispiel:

  • Teamdienstkonto: revenue-reporting-app@proj-A.iam.gserviceaccount.com
  • Kerberos-Teamprinzipal: revenue_reporting/app@EXAMPLE.COM

Diese Methode der Identitätszuordnung bietet einen einzigartigen Ansatz, um eine Kerberos-Identität einem Dienstkonto zuzuordnen, die beide zum selben Team gehören.

Diese Identitäten werden auf verschiedene Arten verwendet:

  • Die Kerberos-Identität gewährt dem Cluster Zugriff auf freigegebene Hadoop-Ressourcen wie den Hive-Metastore.
  • Das Dienstkonto gewährt dem Cluster Zugriff auf freigegebene Google Cloud-Ressourcen wie Cloud Storage.

Mit dieser Methode muss nicht für jedes Teammitglied eine ähnliche Zuordnung erstellt werden. Da diese Methode jedoch ein Dienstkonto oder einen Kerberos-Prinzipal für das gesamte Team verwendet, können Aktionen im Hadoop-Cluster nicht für die einzelnen Mitglieder eines Teams erfasst werden.

Zur Verwaltung des Zugriffs auf Cloud-Ressourcen im Projekt des Teams, die sich außerhalb des Bereichs der Hadoop-Cluster befinden (z. B. Cloud Storage-Buckets, verwaltete Dienste und VMs), fügt ein Administrator die Teammitglieder einer Google-Gruppe hinzu. Der Administrator kann mit der Google Group die IAM-Berechtigungen für das gesamte Team verwalten, um auf Cloud-Ressourcen zuzugreifen.

Wenn Sie einer Gruppe und nicht einzelnen Mitgliedern des Teams IAM-Berechtigungen zuweisen, vereinfachen Sie die Verwaltung des Nutzerzugriffs, wenn Mitglieder dem Anwendungsteam beitreten oder es verlassen. Wenn Sie der Google-Gruppe des Teams direkte IAM-Berechtigungen zuweisen, können Sie die Identitätsübertragung für das Dienstkonto deaktivieren. Dies vereinfacht die Rückverfolgbarkeit von Aktionen in Cloud-Audit-Logs. Wenn Sie die Mitglieder Ihres Teams definieren, sollten Sie den Detaillierungsgrad abwägen, der für die Zugriffsverwaltung, Ressourcennutzung und Prüfung erforderlich ist, und die dafür erforderlichen administrativen Maßnahmen umsetzen.

Wenn ein Cluster ausschließlich einen menschlichen Nutzer (ein einzelmandantenfähiger Cluster) anstelle eines Teams verarbeitet, sollten Sie die private Cluster-Authentifizierung von Dataproc in Betracht ziehen. Cluster mit aktivierter personalisierter Cluster-Authentifizierung sind nur für kurzfristige interaktive Arbeitslasten vorgesehen, um eine Endnutzeridentität sicher auszuführen. Diese Cluster verwenden die IAM-Endnutzeranmeldedaten für die Interaktion mit anderen Google Cloud-Ressourcen wie Cloud Storage. Der Cluster authentifiziert sich als Endnutzer, anstatt sich als Cluster-Dienstkonto zu authentifizieren. Bei diesem Clustertyp wird Kerberos automatisch aktiviert und für die sichere Kommunikation innerhalb des persönlichen Clusters konfiguriert.

Authentifizierungsvorgang

Zum Ausführen eines Jobs in einem Dataproc-Cluster haben Nutzer viele Optionen, wie im vorherigen Abschnitt Jobs senden beschrieben. In allen Fällen muss das Nutzerkonto oder Dienstkonto Zugriff auf den Cluster haben.

Wenn ein Nutzer einen Job in einem Multi-Team-Cluster ausführt, gibt es zwei Möglichkeiten für einen Kerberos-Prinzipal, wie im folgenden Diagramm dargestellt:

Kerberos und Cloud-Identitäten werden mit Multi-Team-Clustern verwendet.

Das obige Diagramm zeigt die folgenden Optionen:

  1. Wenn der Nutzer ein Google Cloud-Tool wie die Dataproc API, Cloud Composer oder das gcloud-Befehlszeilentool verwendet, um die Jobanfrage zu senden, verwendet der Cluster das Dataproc-Kerberos-Hauptkonto, um sich beim KDC zu authentifizieren und auf den Hive-Metastore zuzugreifen.
  2. Wenn der Nutzer einen Job aus einer SSH-Sitzung ausführt, kann er Jobs direkt in dieser Sitzung unter Verwendung seines eigenen Kerberos-Prinzipals senden.

Wenn ein Nutzer einen Job in einem Einzel-Team-Cluster ausführt, ist nur ein möglicher Kerberos-Prinzipal vorhanden, nämlich der Kerberos-Prinzipal des Teams. Dies wird im folgenden Diagramm dargestellt:

Kerberos- und Cloud-Identitäten werden bei Einzel-Team-Clustern verwendet.

Im obigen Diagramm verwendet ein Job das Kerberos-Prinzipal des Teams, wenn der Job Zugriff auf den freigegebenen Hive-Metastore benötigt. Da Single-Team-Cluster nicht mit Kerberos gesichert sind, können Nutzer Jobs über ihr eigenes Nutzerkonto starten.

Bei Einzel-Team-Clustern empfiehlt es sich, kinit für den Teamleiter im Rahmen einer Initialisierungsaktion zum Zeitpunkt der Clustererstellung auszuführen. Verwenden Sie nach dem Erstellen des Clusters einen cron-Zeitplan gemäß der definierten Lebensdauer eines Tickets und verwenden Sie dazu die Befehlsoption "Lebensdauer" (-l). Zum Ausführen von kinit lädt die Initialisierungsaktion zuerst den Keytab auf den Cluster-Masterknoten herunter.

Aus Sicherheitsgründen ist es wichtig, dass Sie den Zugriff auf den Keytab einschränken. Gewähren Sie dem Konto, in dem kinit ausgeführt wird, nur POSIX-Leseberechtigungen. Löschen Sie nach Möglichkeit den Keytab und erneuern Sie das Token mit kinit -R, um seine Lebensdauer mit einem cron-Job zu verlängern, bis die maximale Lebensdauer des Tickets erreicht ist. Zu diesem Zeitpunkt kann der cron-Job den Keytab noch einmal herunterladen, kinit noch einmal ausführen und den Verlängerungszyklus neu starten.

Sowohl Multi-Team- als auch Einzel-Team-Clustertypen verwenden Dienstkonten für den Zugriff auf andere Google Cloud-Ressourcen, zum Beispiel Cloud Storage. Für Einzel-Team-Cluster wird das Teamdienstkonto als Dienstkonto des benutzerdefinierten Clusters verwendet.

Autorisierung

In diesem Abschnitt werden die groben und detaillierten Autorisierungsmechanismen für jeden Cluster beschrieben, wie im folgenden Diagramm gezeigt:

Eine Autorisierungsarchitektur verwendet IAM für eine grobe Autorisierung und Apache Ranger für eine detaillierte Autorisierung.

Die Architektur im vorherigen Diagramm verwendet IAM für eine grobe Autorisierung und Apache Ranger für eine detaillierte Autorisierung. Diese Autorisierungsmethoden werden in den folgenden beiden Abschnitten beschrieben: Grobe Autorisierung und Detaillierte Autorisierung.

Grobe Autorisierung

Mit IAM können Sie den Nutzer- und Gruppenzugriff auf Ihre Projektressourcen steuern. IAM definiert Berechtigungen und die Rollen, die diese Berechtigungen gewähren.

Es gibt vier vordefinierte Dataproc-Rollen: Administrator, Bearbeiter, Betrachter und Worker. Diese Rollen gewähren Dataproc-Berechtigungen, mit denen Nutzer und Dienstkonten bestimmte Aktionen für Cluster, Jobs, Vorgänge und Workflowvorlagen ausführen können. Die Rollen gewähren Zugriff auf die Google Cloud-Ressourcen, die sie für ihre Aufgaben benötigen. Eine dieser Ressourcen ist Cloud Storage, das wir als Cluster-Speicherebene anstelle von HDFS empfehlen.

Der Detaillierungsgrad der IAM-Dataproc-Berechtigungen erstreckt sich nicht auf die Ebene der Dienste, die auf jedem Cluster ausgeführt werden, z. B. Apache Hive oder Apache Spark. Sie können beispielsweise ein bestimmtes Konto autorisieren, um auf Daten in einem Cloud Storage-Bucket zuzugreifen oder Jobs auszuführen. Sie können jedoch nicht festlegen, auf welche Hive-Spalten über dieses Konto mit diesem Job zugegriffen werden kann. Im nächsten Abschnitt wird beschrieben, wie Sie diese Art der detaillierten Autorisierung in Ihren Clustern implementieren können.

Detaillierte Autorisierung

Zum Autorisieren eines detaillierten Zugriffs verwenden Sie die optionale Dataproc Ranger-Komponente in der Architektur, die unter Best Practices für die Verwendung von Apache Ranger in Dataproc beschrieben wird. In dieser Architektur ist Apache Ranger in jedem Ihrer Cluster installiert, sowohl für einzelne als auch für mehrere Teams. Apache Ranger bietet eine detaillierte Zugriffssteuerung für Ihre Hadoop-Anwendungen (Autorisierung und Prüfung) auf Dienst-, Tabellen- oder Spaltenebene.

Apache Ranger verwendet Identitäten, die vom unternehmenseigenen LDAP-Repository bereitgestellt werden und als Kerberos-Prinzipal definiert sind. In Clustern mit mehreren Teams aktualisiert der Ranger-UserSync-Daemon regelmäßig die kerberisierten Identitäten vom unternehmenseigenen LDAP-Server. In Einzel-Team-Clustern ist nur die Teamidentität erforderlich.

Sitzungsspezifische Cluster stellen eine Herausforderung dar, da sie nach Abschluss ihrer Jobs heruntergefahren werden. Sie dürfen jedoch ihre Ranger-Richtlinien und Administratorlogs nicht verlieren. Zur Lösung dieses Problems externalisieren Sie Richtlinien in einer zentralen Cloud SQL-Datenbank und externalisieren Audit-Logs in Cloud Storage-Ordnern. Weitere Informationen finden Sie unter Best Practices für die Verwendung von Apache Ranger auf Dataproc.

Autorisierungsablauf

Wenn ein Nutzer auf einen oder mehrere der Clusterdienste zur Verarbeitung von Daten zugreifen möchte, folgt die Anfrage dem folgenden Ablauf:

  1. Die Authentifizierung erfolgt über eine der im Abschnitt Authentifizierungsablauf beschriebenen Optionen.
  2. Der Zieldienst empfängt die Nutzeranfrage und ruft das entsprechende Apache Ranger-Plug-in auf.
  3. Das Plug-in ruft regelmäßig die Richtlinien vom Ranger Policy Server ab. Diese Richtlinien bestimmen, ob die Nutzeridentität die angeforderte Aktion für den jeweiligen Dienst ausführen darf. Wenn die Nutzeridentität die Aktion ausführen darf, erlaubt das Plug-in dem Dienst die Verarbeitung der Anfrage und der Nutzer ruft die Ergebnisse ab.
  4. Jede Nutzerinteraktion mit einem Hadoop-Dienst, egal ob zugelassen oder abgelehnt, wird vom Ranger-Audit-Server in Ranger-Logs geschrieben. Jeder Cluster hat in Cloud Storage einen eigenen Logordner. Dataproc schreibt außerdem Job- und Clusterlogs, die Sie sich in Cloud Logging ansehen, suchen, filtern und archivieren können.

In diesem Dokument wurden für die Referenzarchitekturen zwei Arten von Dataproc-Clustern verwendet: Multi-Team-Cluster und Einzel-Team-Cluster. Durch die Verwendung mehrerer Dataproc-Cluster, die sich einfach bereitstellen und sichern lassen, kann ein Unternehmen anstelle von herkömmlichen, zentralisierten Clustern einen Job-, Produkt- oder domainorientierten Ansatz verwenden. Dieser Ansatz eignet sich gut für eine allgemeine Data Mesh-Architektur, mit der Teams ihren Data Lake und seine Arbeitslasten vollständig besitzen und schützen sowie Daten als Dienst anbieten können.

Nächste Schritte