Dataproc での Kerberos データレイク

Last reviewed 2024-04-16 UTC

このドキュメントでは、Dataproc のクラスタ上の Key Distribution Center(KDC)Apache Ranger を使用する Google Cloud 上の Kerberos データレイクのネットワーキング、認証、承認のコンセプト、ベスト プラクティス、リファレンス アーキテクチャについて説明します。Dataproc は、Google Cloud のマネージド Hadoop と Spark サービスです。このドキュメントは、従来の Hadoop と Spark のクラスタを Dataproc の最新のデータレイクに移行する Apache Hadoop 管理者、クラウド アーキテクト、ビッグデータ チームを対象としています。

Google Cloud での Kerberos データレイクは、ハイブリッド クラウドとマルチクラウドのデプロイを利用している組織が、既存の IT 投資を ID とアクセス制御の管理に拡張して使用するのに役立ちます。

Google Cloud では、組織は必要な数のジョブスコープのエフェメラル クラスタをチームに提供できます。単一のクラスタでは、依存関係が増えてソフトウェアの構成が多くなると維持管理が複雑になりますが、このアプローチではこのような負担が大幅に軽減されます。組織は、複数のユーザーやサービスがアクセスできるように、より実行時間の長いクラスタを作成することもできます。このドキュメントでは、Kerberos や Apache Ranger などの業界標準ツールを使用して、Dataproc の両方のクラスタケースできめ細かなユーザー セキュリティ(認証、認可、監査)を可能にする方法について説明します。

お客様のユースケース

企業では、従来の Hadoop の管理に伴う課題を解決するために、オンプレミスの Hadoop ベースのデータレイクをパブリック クラウド プラットフォームの移行が進められています。

こうした企業の一つがエンタープライズ ソフトウェアおよびハードウェアの大手テクノロジー リーダーであり、オンプレミスの Hadoop システムを Google Cloud に移行することを決定しました。そのオンプレミス Hadoop 環境は、200 人のデータ分析チームメンバーを抱えるサイバーセキュリティ チームなど、数百のチームやビジネス ユニットの分析ニーズに対応していました。しかし、リソースの柔軟性に欠けるため、1 人のチームメンバーが従来のデータレイクで大規模なクエリを実行すると問題が生じました。組織は、オンプレミス環境を使用するチームの分析ニーズに対応するのに苦労していたため、Google Cloud に移行しました。Google Cloud に移行したことで、このオンプレミス データレイクで報告される問題の数を毎月 25% 減少させることに成功しました。

Google Cloud への組織移行計画の基盤は、チームのワークロードに従って大規模なモノリシック クラスタを再構築して最適化し、クラスタ管理からビジネス価値の創出に焦点を移すことでした。少数の大規模なクラスタを、費用対効果に優れた小さな Dataproc クラスタに分割し、ワークロードとチームを次のタイプのモデルに移行しました。

  • エフェメラル ジョブスコープ クラスタ: エフェメラル モデルでは、数分のスピンアップ時間で、ジョブまたはワークフローで専用クラスタを使用できるようになります。これらのクラスタはジョブの完了時にシャットダウンされます。このパターンでは、Dataproc の組み込み Hadoop 用 Cloud Storage コネクタを使用して、Hadoop 分散ファイル システム(HDFS)を Cloud Storage に置き換えることで、ストレージをコンピューティング ノードから切り離します。
  • 準長時間実行クラスタ: 短時間のジョブ限定クラスタがユースケースに対応できない場合、Dataproc クラスタは長時間実行される可能性があります。クラスタのステートフル データを Cloud Storage にオフロードすると、クラスタを簡単にシャットダウンでき、長時間実行と見なされます。また、スマートなクラスタ自動スケーリングにより、こうしたクラスタを小規模で起動し、特定のアプリケーションに合わせてコンピューティング リソースを最適化することもできます。この自動スケーリングは、YARN キューの管理に代わるものです。

ハイブリッド セキュリティの課題

上記のシナリオでは、お客様は大規模なデータ管理システムをクラウドに移行しました。ただし、組織の IT の他の部分(たとえば、データレイクにフィードするレガシー オペレーティング システムの一部)はオンプレミスに残す必要がありました。

オンプレミスの中心的な LDAP ベースの ID プロバイダ(IdP)がデータレイクを使用する企業 ID の信頼できるソースであり続けるために、セキュリティ アーキテクチャが必要でした。オンプレミスの Hadoop セキュリティは、認証に Kerberos と LDAP(組織の Microsoft Active Directory(AD)の一部として組み込まれています)と他のいくつかのオープンソース ソフトウェア(OSS)プロダクト(Apache Ranger など)を使用しています。このセキュリティ アプローチでは、データレイク クラスタでのユーザーのアクティビティとチームのアクティビティをきめ細かく認可して監査できます。Google Cloud では、Identity and Access Management(IAM)を使用して、Dataproc や Cloud Storage などの特定の Google Cloud リソースへのアクセスを管理します。

このドキュメントでは、オンプレミスと OSS Hadoop セキュリティ(Kerberos、企業 LDAP、Apache Ranger が中心)のメリットを最大限に活用したセキュリティ アプローチと、Hadoop クラスタ内外のワークロードとデータの保護に役立つ IAM について説明します。

アーキテクチャ

次の図は、アーキテクチャの概要を示しています。

Dataproc を使用した Google Cloud での Kerberos データレイクのアーキテクチャの概要。

上の図では、クライアントはマルチチーム クラスタまたは単一チームのクラスタでジョブを実行します。クラスタでは、中央の Hive メタストア、および企業 ID プロバイダによる Kerberos 認証を使用します。

コンポーネント

このアーキテクチャでは、業界標準のオープンソース ツールと IAM を組み合わせた、ジョブの送信方法の認証と認可を提案します。これについては、このドキュメントで後ほど説明します。Hadoop クラスタ内でチームとユーザーのワークロードをきめ細かく保護するために連携して機能する主要コンポーネントは次のとおりです。

  • Kerberos: Kerberos は、秘密鍵暗号を使用してクライアント / サーバー アプリケーションに強力な認証を提供するネットワーク認証プロトコルです。Kerberos サーバーは Key Distribution Center(KDC)と呼ばれています。

    Kerberos は、AD などのオンプレミス システムで広く使用され、人間のユーザー、サービス、マシンを認証します(クライアント エンティティはユーザー プリンシパルと表記されます)。Dataproc で Kerberos を有効にすると、無料の MIT の Kerberos ディストリビューションを使用して、クラスタ上に KDC が作成されます。Dataproc のクラスタ上の KDC は、ユーザー プリンシパルが Apache Hadoop YARNHDFSApache Spark などのクラスタ内のリソース(サーバー リソースはサービス プリンシパルと呼ばれます)にアクセスできるようにします。Kerberos のレルム間の信頼により、レルムのプリンシパルを別のレルムに接続できます。

  • Apache Ranger: Apache Ranger は、ユーザーが Hadoop サービスで特定のアクションを実行するための詳細に制御された権限を付与します。また、ユーザー アクセスを監査し、管理アクションを実装します。Ranger は、オンプレミスの企業 LDAP サーバーまたは AD と同期して、ユーザーとサービスの ID を取得できます。

  • 共有 Hive メタストア: Hive メタストアは、Apache Hive や他の Hadoop ツールのメタデータを保存するサービスです。これらのツールの多くはこれに基づいて構築されているため、Hive メタストアは多くのデータレイクの重要なコンポーネントになっています。提案するアーキテクチャでは、一元化された Kerberos 対応 Hive メタストアにより、複数のクラスタが安全にメタデータを共有できます。

Kerberos、Ranger、共有 Hive メタストアは相互に連携して、Hadoop クラスタ内のきめ細かなユーザー セキュリティを実現しますが、IAM は Google Cloud リソースへのアクセスを制御します。たとえば、Dataproc は Dataproc サービス アカウントを使用して、Cloud Storage バケットに対する読み取りと書き込みを実行します。

クラスタの種類

Dataproc クラスタには、次の種類があります。

  • テナンシー: 複数のユーザーまたはサービスのリクエストを処理する場合、クラスタはマルチテナントになります。また、1 つのユーザーまたはサービスのリクエストを処理する場合、クラスタは単一テナントです。
  • Kerberos: Dataproc で Kerberos を有効にする場合、クラスタは Kerberos になり、Dataproc で Kerberos を有効にしない場合は非 Kerberos になります。
  • ライフサイクル: 特定のジョブまたはワークフローの期間だけ作成されたクラスタは、そのジョブの実行に必要なリソースのみを含むエフェメラルになり、ジョブが完了するとシャットダウンされます。それ以外の場合、クラスタは準長時間実行とみなされます。

これらの組み合わせによって、特定のクラスタが最も適しているユースケースが決まります。このドキュメントでは、次の代表的な例について説明します。

  1. アーキテクチャに示されているマルチチーム クラスタは、Kerberos、マルチテナント、準長時間実行のクラスタです。これらのクラスタは、インタラクティブなクエリ ワークロード(長期的なデータ分析やビジネス インテリジェンス(BI)の探索など)に最適です。このアーキテクチャでは、クラスタは複数のチームで共有されている Google Cloud プロジェクトに配置され、各チームのリクエストを処理しています。

    このドキュメントでは、「チーム」または「アプリケーション チーム」という用語は、同じソフトウェア コンポーネントを使用している、または 1 つの機能的なチームとしての役割を果たしているグループを意味します。たとえば、マイクロサービスのバックエンド デベロッパーや、ビジネス アプリケーションの BI アナリスト、ビッグデータ インフラストラクチャ チームなどのクロスファンクショナルなチームを指しています。

  2. アーキテクチャに示されている単一チームクラスタは、マルチテナント(同じチームのメンバー)または単一テナントのクラスタです。

  • エフェメラル クラスタとして、単一チームクラスタは、データ エンジニアによる Spark バッチ処理ジョブの実行や、データ サイエンティストによるモデルのトレーニング ジョブなどのジョブに使用できます。
  • 準長時間実行クラスタであるため、単一チームクラスタは、単一のチームまたは個人をスコープとするデータ分析と BI ワークロードに対応できます。

    単一チームクラスタは、単一チームに属する Google Cloud プロジェクトに配置されます。これにより、使用状況の監査、課金、リソースの分離が簡単になります。たとえば、その単一チームのメンバーのみが、クラスタのデータを永続化させるために使用される Cloud Storage バケットにアクセスできます。このアプローチでは、アプリケーション チームに専用のプロジェクトがあるため、単一チームのクラスタは Kerberos に対応していません。

個々の要件を分析し、最適な組み合わせを選択することをおすすめします。

ジョブの送信

ユーザーは、次のものを含む各種ツールを使用して、両方のタイプのクラスタにジョブを送信できます。

  • REST 呼び出しまたはクライアント ライブラリを使用する Dataproc API
  • Google Cloud CLI gcloud コマンドライン ツール。ローカル ターミナル ウィンドウから実行するか、ローカル ブラウザで開いた Google Cloud コンソールの Cloud Shell から使用します。
  • Dataproc ワークフロー テンプレート。再利用可能なワークフロー構成で、ジョブをどこで実行するかに関する情報によってジョブのグラフを定義します。ワークフローでマネージド クラスタ オプションを使用する場合は、エフェメラル クラスタを使用します。
  • Cloud ComposerDataproc Operator を使用します。Composer 有向非巡回グラフ(DAG)は、Dataproc ワークフロー テンプレートのオーケストレーションにも使用できます。
  • クラスタでマスターノードへの SSH セッションを開いてジョブを直接送信できます。または、Apache Beeline などのツールを使用して処理できます。このツールは通常、管理者とパワーユーザー専用に予約されています。パワーユーザーの例としては、サービスの構成パラメータのトラブルシューティングを行い、マスターノードでテストジョブを直接実行して検証するデベロッパーなどが挙げられます。

ネットワーキング

次の図は、アーキテクチャのネットワーキングのコンセプトを示しています。

ハイブリッド メッシュ パターンを使用するネットワーキング アーキテクチャ。

上の図では、ネットワーキング アーキテクチャはメッシュ型ハイブリッド パターンを使用しています。このパターンでは、一部のリソースは Google Cloud 上に配置され、一部がオンプレミスにあります。メッシュ型ハイブリッド パターンでは、共有 VPC を使用します。これは、共通のホスト プロジェクトと、Dataproc クラスタタイプとチームごとに別個のプロジェクトを使用します。このアーキテクチャの詳細については、次の Google Cloudオンプレミスのセクションをご覧ください。

Google Cloud

Google Cloud では、共有 VPC を使用してアーキテクチャを構築します。共有 VPC を使用すると、複数のプロジェクトのリソースを共通の VPC ネットワークに接続できます。共通の VPC ネットワークを使用すると、そのネットワークの内部 IP アドレスを使用して、安全で効率的な相互通信ができます。共有 VPC を設定するには、次のプロジェクトを作成します。

  • ホスト プロジェクト: ホスト プロジェクトには、すべてのサービス プロジェクトで使用される 1 つ以上の共有 VPC ネットワークが含まれます。
  • サービス プロジェクト: サービス プロジェクトには、関連する Google Cloud リソースが含まれます。共有 VPC 管理者は、サービス プロジェクトをホスト プロジェクトに接続し、共有 VPC ネットワーク内のサブネットとリソースの使用を許可します。この接続は、単一チームのクラスタが一元化された Hive メタストアにアクセスするために不可欠です。

    ネットワーキングの図に示すように、Hive メタストア クラスタ、マルチチーム クラスタ、各チームのクラスタに別々のサービス プロジェクトを作成することをおすすめします。組織の各チームメンバーが、それぞれのプロジェクト内に単一チームのクラスタを作成できるようになります。

ハイブリッド ネットワーク内のコンポーネントが通信できるようにするには、次のトラフィックを許可するようにファイアウォール ルールを構成する必要があります。

  • Hadoop サービス用の内部クラスタ トラフィック。HDFS NameNode は HDFS DataNode と通信し、YARN ResourceManager は YARN NodeManager と通信します。これらのルールでは、クラスタのサービス アカウントでのフィルタリングを使用することをおすすめします。
  • Hive メタストア(ポート tcp:9083,8020)、オンプレミス KDC(ポート tcp:88)、LDAP(ポート 636)などと通信する特定のポート上の外部クラスタ トラフィックと、特定のシナリオ(Google Kubernetes Engine(GKE)上の Kafka など)で使用する一元化された外部サービス。

このアーキテクチャのすべての Dataproc クラスタは、内部 IP アドレスのみで作成されます。クラスタノードが Google API とサービスにアクセスできるようにするには、クラスタ サブネットで限定公開の Google アクセスを有効にする必要があります。管理者とパワーユーザーがプライベート IP アドレスの VM インスタンスにアクセスできるようにするには、IAP TCP 転送を使用して、暗号化されたトンネルを介して SSH、RDP などのトラフィックを転送します。

クラスタ アプリケーションとオプション コンポーネント(Spark、Hadoop、Jupyter、Zeppelin など)のクラスタ ウェブ インターフェースには、Dataproc Component Gateway を介して安全にアクセスできます。Dataproc Component Gateway は、Apache Knox をベースとする HTTP 反転プロキシです。

オンプレミス

このドキュメントでは、オンプレミスに配置されているリソースが企業の LDAP ディレクトリ サービスであり、ユーザーおよびチームのサービス プリンシパルが定義されている企業の Kerberos Key Distribution Center(KDC)であることを前提としています。オンプレミスの ID プロバイダを使用する必要がない場合は、Dataproc クラスタまたは仮想マシンで Cloud Identity と KDC を使用して設定を簡素化できます。

オンプレミスの LDAP や KDC と通信するには、Cloud Interconnect または Cloud VPN を使用します。この設定により、RFC 1918 IP アドレスのサブネットワークで重複がない場合、環境間の通信でプライベート IP アドレスが使用されます。さまざまな接続オプションの詳細については、Network Connectivity プロダクトの選択をご覧ください。

ハイブリッド シナリオでは、認証リクエストを最小限のレイテンシで処理する必要があります。この目標を達成するには、次の方法を使用できます。

  • クラスタ上の KDC からサービス ID のすべての認証リクエストを処理し、ユーザー ID にはクラスタの外部の ID プロバイダのみを使用します。ほとんどの認証トラフィックは、サービス ID からのリクエストである必要があります。
  • AD を ID プロバイダとして使用している場合、ユーザー プリンシパル名(UPN)は、人間のユーザーと AD サービス アカウントを表します。UPN をオンプレミス AD から、データレイク クラスタに近い Google Cloud リージョンに複製することをおすすめします。この AD レプリカは UPN の認証リクエストを処理するため、リクエストがオンプレミス AD に転送されることはありません。各クラスタ上の KDC は、最初の手法を使用してサービス プリンシパル名(SPN)を処理します。

次の図は、両方の手法を使用するアーキテクチャを示しています。

オンプレミスの AD が UPN を AD レプリカに同期し、クラスタ上の KDC が UPN と SPN を認証します。

上の図では、オンプレミス AD が UPN を Google Cloud リージョンの AD レプリカに同期しています。AD レプリカが UPN を認証し、クラスタ上の KDC が SPN を認証します。

Google Cloud に AD をデプロイする方法については、フォールト トレラントな Microsoft Active Directory 環境のデプロイをご覧ください。ドメイン コントローラーのインスタンス数のサイズを設定する方法については、MIT Kerberos と Active Directory の統合をご覧ください。

認証

次の図は、さまざまな Hadoop クラスタ内のユーザーの認証に使用されるコンポーネントを示しています。認証を使用すると、ユーザーは Apache HiveApache Spark などのサービスを使用できます。

コンポーネントは、さまざまな Hadoop クラスタ内のユーザーを認証します。

上の図では、Kerberos レルムでクラスタがレルム間の信頼を設定し、Hive メタストアなどの他のクラスタでサービスを使用するように設定できます。Kerberos に対応していないクラスタでは、Kerberos クライアントとアカウント keytab を使用して他のクラスタでサービスを使用できます。

共有および保護された Hive メタストア

一元化された Hive メタストアにより、さまざまなオープンソース クエリエンジン(Apache Spark、Apache Hive/Beeline、Presto など)を実行する複数のクラスタでメタデータを共有できます。

Kerberos クラスタ Dataproc に Hive メタストア サーバーをデプロイし、Cloud SQL 上の MySQL インスタンスなどのリモート RDBMS に Hive メタストア データベースをデプロイします。共有サービスとして、Hive メタストア クラスタは認証済みのリクエストのみを処理します。Hive メタストアの構成の詳細については、Dataproc での Apache Hive の使用をご覧ください。

Hive メタストアの代わりに、Dataproc Metastore を使用できます。これは、フルマネージドで、リージョン内での高可用性を有している、サーバーレスの Apache Hive メタストアです。サービスの Kerberos の構成