このドキュメントでは、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 について説明します。
アーキテクチャ
次の図は、アーキテクチャの概要を示しています。
上の図では、クライアントはマルチチーム クラスタまたは単一チームのクラスタでジョブを実行します。クラスタでは、中央の Hive メタストア、および企業 ID プロバイダによる Kerberos 認証を使用します。
コンポーネント
このアーキテクチャでは、業界標準のオープンソース ツールと IAM を組み合わせた、ジョブの送信方法の認証と認可を提案します。これについては、このドキュメントで後ほど説明します。Hadoop クラスタ内でチームとユーザーのワークロードをきめ細かく保護するために連携して機能する主要コンポーネントは次のとおりです。
Kerberos: Kerberos は、秘密鍵暗号を使用してクライアント / サーバー アプリケーションに強力な認証を提供するネットワーク認証プロトコルです。Kerberos サーバーは Key Distribution Center（KDC）と呼ばれています。
Kerberos は、AD などのオンプレミス システムで広く使用され、人間のユーザー、サービス、マシンを認証します（クライアント エンティティはユーザー プリンシパルと表記されます）。Dataproc で Kerberos を有効にすると、無料の MIT の Kerberos ディストリビューションを使用して、クラスタ上に KDC が作成されます。Dataproc のクラスタ上の KDC は、ユーザー プリンシパルが Apache Hadoop YARN、HDFS、Apache 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 になります。
- ライフサイクル: 特定のジョブまたはワークフローの期間だけ作成されたクラスタは、そのジョブの実行に必要なリソースのみを含むエフェメラルになり、ジョブが完了するとシャットダウンされます。それ以外の場合、クラスタは準長時間実行とみなされます。
これらの組み合わせによって、特定のクラスタが最も適しているユースケースが決まります。このドキュメントでは、次の代表的な例について説明します。
アーキテクチャに示されているマルチチーム クラスタは、Kerberos、マルチテナント、準長時間実行のクラスタです。これらのクラスタは、インタラクティブなクエリ ワークロード（長期的なデータ分析やビジネス インテリジェンス（BI）の探索など）に最適です。このアーキテクチャでは、クラスタは複数のチームで共有されている Google Cloud プロジェクトに配置され、各チームのリクエストを処理しています。
このドキュメントでは、「チーム」または「アプリケーション チーム」という用語は、同じソフトウェア コンポーネントを使用している、または 1 つの機能的なチームとしての役割を果たしているグループを意味します。たとえば、マイクロサービスのバックエンド デベロッパーや、ビジネス アプリケーションの BI アナリスト、ビッグデータ インフラストラクチャ チームなどのクロスファンクショナルなチームを指しています。
アーキテクチャに示されている単一チームクラスタは、マルチテナント（同じチームのメンバー）または単一テナントのクラスタです。
- エフェメラル クラスタとして、単一チームクラスタは、データ エンジニアによる Spark バッチ処理ジョブの実行や、データ サイエンティストによるモデルのトレーニング ジョブなどのジョブに使用できます。
準長時間実行クラスタであるため、単一チームクラスタは、単一のチームまたは個人をスコープとするデータ分析と BI ワークロードに対応できます。
単一チームクラスタは、単一チームに属する Google Cloud プロジェクトに配置されます。これにより、使用状況の監査、課金、リソースの分離が簡単になります。たとえば、その単一チームのメンバーのみが、クラスタのデータを永続化させるために使用される Cloud Storage バケットにアクセスできます。このアプローチでは、アプリケーション チームに専用のプロジェクトがあるため、単一チームのクラスタは Kerberos に対応していません。
個々の要件を分析し、最適な組み合わせを選択することをおすすめします。
ジョブの送信
ユーザーは、次のものを含む各種ツールを使用して、両方のタイプのクラスタにジョブを送信できます。
- REST 呼び出しまたはクライアント ライブラリを使用する Dataproc API。
- Google Cloud CLI gcloud コマンドライン ツール。ローカル ターミナル ウィンドウから実行するか、ローカル ブラウザで開いた Google Cloud コンソールの Cloud Shell から使用します。
- Dataproc ワークフロー テンプレート。再利用可能なワークフロー構成で、ジョブをどこで実行するかに関する情報によってジョブのグラフを定義します。ワークフローでマネージド クラスタ オプションを使用する場合は、エフェメラル クラスタを使用します。
- Cloud Composer。Dataproc 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 を Google Cloud リージョンの AD レプリカに同期しています。AD レプリカが UPN を認証し、クラスタ上の KDC が SPN を認証します。
Google Cloud に AD をデプロイする方法については、フォールト トレラントな Microsoft Active Directory 環境のデプロイをご覧ください。ドメイン コントローラーのインスタンス数のサイズを設定する方法については、MIT Kerberos と Active Directory の統合をご覧ください。
認証
次の図は、さまざまな Hadoop クラスタ内のユーザーの認証に使用されるコンポーネントを示しています。認証を使用すると、ユーザーは Apache Hive や Apache Spark などのサービスを使用できます。
上の図では、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 の構成で説明されているように、Dataproc Metastore サービスで Kerberos を有効にすることもできます。
Kerberos
このアーキテクチャでは、マルチチーム クラスタを分析目的で使用し、Dataproc セキュリティ構成のガイドに従って Kerberos に対応させます。Dataproc セキュアモードは、クラスタ上の KDC を作成し、Hadoop セキュアモードの仕様で要求されているように、クラスタのサービス プリンシパルと keytab を管理します。
keytab は、Kerberos プリンシパルの 1 つ以上のペアと、そのプリンシパルの鍵の暗号化されたコピーを含むファイルです。keytab は、kinit コマンドを使用したインタラクティブなログインが実行不可能な場合、プログラムによる Kerberos 認証を許可します。
keytab へのアクセスとは、keytab に含まれるプリンシパルの権限を借用する機能を指します。したがって、keytab は機密性が高いファイルであり、安全に転送と保存を行う必要があります。keytab の内容は、それぞれのクラスタに転送する前に、Secret Manager を使用して保存することをおすすめします。keytab の内容を保存する方法の例については、サービスの Kerberos の構成をご覧ください。keytab をクラスタ マスターノードにダウンロードした後、そのファイルでファイル アクセス権限を制限する必要があります。
クラスタ上の KDC は、そのクラスタ内のすべてのサービスに対する認証リクエストを処理します。ほとんどの認証リクエストは、このタイプのリクエストである必要があります。レイテンシを最小限に抑えるには、KDC がクラスタから離れずにリクエストを解決することが重要です。
残りのリクエストは、人間のユーザーと AD サービス アカウントからのリクエストです。上記のオンプレミス セクションで説明したように、Google Cloud の AD レプリカまたはオンプレミスの中央 ID プロバイダがこれらのリクエストを処理します。
このアーキテクチャでは、単一チームのクラスタは Kerberos に対応しないため、KDC は存在しません。これらのクラスタが共有 Hive メタストアにアクセスできるようにするには、Kerberos クライアントをインストールするだけです。アクセスを自動化するには、チームの keytab を使用します。詳細については、このドキュメントの後半の ID マッピングをご覧ください。
マルチチーム クラスタでの Kerberos レルム間の信頼
ワークロードがハイブリッドまたはマルチクラウドの場合、レルム間信頼が非常に重要になります。レルム間の信頼により、中央の企業 ID を Google Cloud データレイクで使用可能な共有サービスに統合できます。
Kerberos では、レルムは共通の KDC の下にあるシステムのグループを定義します。クロスレルム認証では、あるレルムのユーザー プリンシパルが別のレルムで認証し、そのサービスを使用できます。この構成では、レルム間の信頼を確立する必要があります。
アーキテクチャには、次の 3 つのレルムがあります。
- EXAMPLE.COM: 企業レルムであり、ユーザー、チーム、サービスの Kerberos ユーザー プリンシパルが定義されます（UPN）。
- MULTI.EXAMPLE.COM: マルチチーム クラスタを含むレルムです。クラスタには、Apache Spark や Apache Hive などの Hadoop サービスのサービス プリンシパル（SPN）があらかじめ構成されています。
- METASTORE.EXAMPLE.COM: Hive メタストアのレルムです。
単一チームのクラスタは Kerberos に対応しないため、レルムには属しません。
すべてのクラスタで企業ユーザー プリンシパルを使用できるようにするには、次の単一方向のレルム間の信頼を確立します。
企業レルムを信頼するようにマルチチーム レルムとメタストアのレルムを構成します。この構成では、企業レルムで定義されているプリンシパルは、マルチチーム クラスタとメタストアにアクセスできます。
信頼は推移的であっても問題ありませんが、企業領域に直接信頼を確立するようにメタストアの領域を構成することをおすすめします。この構成では、マルチチーム レルムの可用性に依存することを回避します。
メタストア レルムがマルチチーム レルムを信頼するように構成して、マルチチーム クラスタがメタストアにアクセスできるようにします。この構成は、HiveServer2 プリンシパルにメタストアへのアクセスを許可するために必要です。
詳細については、レルム間の信頼がある Kerberos クラスタ Dataproc のスタートガイドと、GitHub リポジトリ内の対応する Terraform 構成ファイルをご覧ください。
マルチチーム クラスタに対する組み込みまたはクラウドネイティブな IAM のアプローチが必要な場合と、ハイブリッド ID 管理が不要な場合は、Dataproc サービス アカウント ベースの安全なマルチテナンシーの使用を検討してください。こうしたクラスタでは、複数の IAM ID が、それぞれ異なるサービス アカウントとして Cloud Storage やその他の Google リソースにアクセスできます。
単一チームのクラスタでの ID マッピング
これまでのセクションでは、アーキテクチャの Kerberos 側の構成について説明しました。ただし、単一チームのクラスタは、Kerberos に対応していないため、このエコシステムに参加できるようにするには、特別な手法が必要になります。この手法では、Google Cloud プロジェクトの分離プロパティと IAM サービス アカウントを使用して、アプリケーション チームの Hadoop ワークロードを分離し、保護します。
前のネットワーキング セクションで説明したように、各チームには対応する Google Cloud プロジェクトがあり、そこで単一チームのクラスタを作成できます。単一チームクラスタ内では、チームの 1 人以上のメンバーがクラスタのテナントです。プロジェクトごとに分離するこの方法では、これらのクラスタで使用されている Cloud Storage バケットへのアクセスが、それぞれのチームに限定されます。
管理者がサービス プロジェクトを作成し、そのプロジェクト内でチームのサービス アカウントをプロビジョニングします。クラスタを作成する場合、このサービス アカウントはクラスタ サービス アカウントとして指定されます。
また、管理者が企業のレルムでチームの Kerberos プリンシパルを作成し、対応する keytab を作成します。keytab は Secret Manager に安全に保管され、管理者はその keytab をクラスタ マスターノードにコピーします。Kerberos プリンシパルは、単一チームのクラスタから Hive メタストアへのアクセスを許可します。
自動プロビジョニングを促進し、関連する ID のペアを簡単に認識できるように、ID は共通の命名規則に従ったものにする必要があります。次に例を示します。
- チームのサービス アカウント:
[email protected] - Kerberos チーム プリンシパル:
revenue_reporting/[email protected]
この ID マッピングの手法は、同じチームに属する Kerberos の ID をサービス アカウントにマッピングする独自の方法です。
これらの ID はさまざまな方法で使用されます。
- Kerberos ID を使用すると、クラスタは Hive メタストアなどの共有 Hadoop リソースにアクセスできます。
- サービス アカウントを使用すると、クラスタに Google Cloud の共有リソース（Cloud Storage など）へのアクセスを許可できます。
この手法により、チームのそれぞれのメンバーに同様のマッピングを作成する必要がなくなります。ただし、この方法ではチーム全体で 1 つのサービス アカウントまたは Kerberos プリンシパルを使用するため、Hadoop クラスタ内のアクションをチームの個々のメンバーにいたるまで追跡することはできません。
Hadoop クラスタの範囲外にあるチームのプロジェクト内のクラウド リソース（Cloud Storage バケット、マネージド サービス、VM など）へのアクセスを管理するには、管理者がチームメンバーを Google グループに追加する必要があります。管理者は Google グループを使用して、クラウド リソースにアクセスするためのチーム全体の IAM 権限を管理できます。
チームの個々のメンバーではなくグループに IAM 権限を付与すると、メンバーがアプリケーション チームに参加または離脱するときにユーザー アクセスの管理を簡素化できます。IAM 権限をチームの Google グループに直接付与することで、サービス アカウントの権限借用を無効にできます。これにより、Cloud Audit Logs でのアクションのトレーサビリティが簡素化されます。チームメンバーを定義するときは、アクセス管理、リソースの使用量、およびそれらのタスクから派生する管理作業の監査に必要な粒度のバランスをとることをおすすめします。
クラスタがチームではなく 1 人のユーザー（単一テナントのクラスタ）にサービスを提供する場合は、Dataproc 個人用クラスタ認証の使用を検討してください。個人用クラスタ認証が有効になっているクラスタは、1 つのエンドユーザー ID として安全に動作する短期間のインタラクティブなワークロードのみを対象としています。これらのクラスタは、IAM エンドユーザー認証情報を使用して、Cloud Storage などの他の Google Cloud リソースとやり取りします。クラスタは、クラスタ サービス アカウントとして認証するのではなく、エンドユーザーとして認証します。このタイプのクラスタでは、個人用クラスタ内での安全な通信のために Kerberos が自動的に有効になり、構成されます。
認証フロー
前述のジョブの送信セクションで説明したように、Dataproc クラスタでジョブを実行するために、ユーザーは多くのオプションを使用できます。いずれの場合も、ユーザー アカウントまたはサービス アカウントはクラスタへのアクセス権が与えられている必要があります。
次の図に示すように、ユーザーがマルチチーム クラスタでジョブを実行する場合、Kerberos プリンシパルの 2 つの選択肢があります。
上の図は次のオプションを示しています。
- ユーザーが Google Cloud ツール（Dataproc API、Cloud Composer、gcloud コマンドライン ツールなど）を使用してジョブ リクエストを送信すると、クラスタはDataproc Kerberos プリンシパルを使用して KDC で認証し、Hive メタストアにアクセスします。
- ユーザーが SSH セッションからジョブを実行する場合、ユーザーは自身のユーザー Kerberos プリンシパルを使用して、対象セッションでジョブを直接送信できます。
次の図に示すように、ユーザーが単一チームのクラスタでジョブを実行する場合、可能性のある Kerberos プリンシパル（チームの Kerberos プリンシパル）は 1 つだけです。
上の図で、ジョブが共有 Hive メタストアにアクセスする必要がある場合、ジョブはチーム Kerberos プリンシパルを使用します。それ以外の場合は、単一チームのクラスタは Kerberos に対応していないため、ユーザーは自身のユーザー アカウントを使用してジョブを開始できます。
単一チームクラスタの場合、クラスタ作成時に初期化アクションの一環として、チーム プリンシパルに対して kinit を実行することをおすすめします。クラスタの作成後、lifetime（-l）コマンド オプションを使用して、定義されたチケットの有効期間に従って cron スケジュールを使用します。kinit を実行するには、初期化アクションによって最初に keytab がクラスタ マスターノードにダウンロードされます。
セキュリティ上の理由から、keytab へのアクセスを制限することが不可欠です。POSIX 読み取り権限を kinit を実行するアカウントのみに付与します。可能であれば、keytab を削除して、kinit -R を使用してトークンを更新し、チケットの最大有効時間に達するまで cron ジョブの使用の有効期間を延長します。その時点で、cron ジョブは keytab を再ダウンロードし、kinit を再実行して、更新サイクルを再開できます。
マルチチーム クラスタタイプと単一チーム クラスタタイプはどちらも、サービス アカウントを使用して Cloud Storage などの他の Google Cloud リソースにアクセスします。単一チームのクラスタでは、チームのサービス アカウントをカスタム クラスタのサービス アカウントとして使用します。
認可
このセクションでは、次の図に示すように、各クラスタの大まかな認可メカニズムときめ細かい認可メカニズムについて説明します。
上の図のアーキテクチャでは、大まかな認可に IAM が使用され、きめ細かい認可に Apache Ranger が使用されています。この認可方法については、大まかな認可ときめ細かい認可をご覧ください。
大まかな認可
IAM を使用すると、プロジェクトのリソースに対するユーザーとグループのアクセスを制御できます。IAM は権限と、これらの権限を付与するロールを定義します。
事前定義された Dataproc のロールには、管理者、編集者、閲覧者、ワーカーの 4 つがあります。これらのロールは、ユーザーとサービス アカウントがクラスタ、ジョブ、オペレーション、ワークフロー テンプレートに対して特定のアクションを実行できるようにする Dataproc 権限を付与します。このロールは、タスクの実行に必要な Google Cloud リソースへのアクセスを許可します。これらのリソースの 1 つは Cloud Storage で、HDFS ではなくクラスタ ストレージ レイヤとして使用することをおすすめします。
IAM Dataproc の権限の粒度は、Apache Hive や Apache Spark など、各クラスタで実行されているサービスのレベルには及びません。たとえば、特定のアカウントに Cloud Storage バケットからのデータへのアクセスやジョブの実行を許可できますが、そのアカウントでジョブにアクセスできる Hive 列は指定できません。次のセクションでは、クラスタ内でこのようなきめ細かい認可を実装する方法について説明します。
きめ細かい認可
きめ細かいアクセスを許可するには、Dataproc で Apache Ranger を使用する場合のベスト プラクティスで説明されているアーキテクチャで Dataproc Ranger のオプション コンポーネントを使用します。このアーキテクチャでは、Apache Ranger は各クラスタ（単一チームとマルチチームの両方）にインストールされます。Apache Ranger は、Hadoop アプリケーションに対するきめ細かなアクセス制御（認可と監査）をサービス、テーブル、列のレベルで実現します。
Apache Ranger は、企業 LDAP リポジトリによって提供され、Kerberos プリンシパルとして定義された ID を使用します。マルチチーム クラスタでは、Ranger UserSync デーモンが Kerberos 対応の ID を企業の LDAP サーバーから定期的に更新します。単一チームのクラスタでは、チームの ID のみが必要です。
エフェメラル クラスタでは、ジョブの完了後にシャットダウンするために課題がありますが、Ranger ポリシーと管理ログが失われることはありません。この課題に対処するには、ポリシーを中央の Cloud SQL データベースに外部化し、監査ログを Cloud Storage フォルダに外部化します。詳細については、Dataproc で Apache Ranger を使用する場合のベスト プラクティスをご覧ください。
認可フロー
ユーザーがデータ処理のために 1 つ以上のクラスタ サービスにアクセスする場合、リクエストは次のフローで処理されます。
- ユーザーが認証フロー セクションに記載されているオプションのいずれかを使用して認証されます。
- 対象のサービスがユーザー リクエストを受け取り、対応する Apache Ranger プラグインを呼び出します。
- プラグインは、Ranger ポリシー サーバーから定期的にポリシーを取得します。これらのポリシーによって、特定のユーザー ID に対し、それぞれのサービスでリクエストされた操作が許可されるかが判断されます。ユーザー ID でアクションの実行が許可されている場合、プラグインはサービスのリクエスト処理を許可して、ユーザーがその結果を取得します。
- ユーザーが Hadoop サービスに対して行う操作は、許可されたものも拒否されたものも含め、すべてが Ranger 監査サーバーによって Ranger ログに記録されます。Cloud Storage には、各クラスタ固有のログフォルダがあります。Dataproc はジョブログとクラスタログを書き込みます。このログは、Cloud Logging で表示、検索、フィルタ、アーカイブできます。
このドキュメントでは、リファレンス アーキテクチャで、マルチチーム クラスタと単一チームクラスタの 2 種類の Dataproc クラスタを使用しました。プロビジョニングとセキュリティ保護が容易な複数の Dataproc クラスタを使用することで、組織では従来の一元的なクラスタの代わりに、ジョブ、プロダクト、またはドメインに特化したアプローチを使用できます。このアプローチは、データメッシュ アーキテクチャ全体とうまく連携します。これにより、チームはデータレイクとそのワークロードを完全に所有および保護し、データをサービスとして提供できます。
次のステップ
- レルム間の信頼がある Kerberos クラスタ Dataproc スタートガイドと、GitHub リポジトリ内の対応する Terraform 構成ファイルを確認する。
- Dataproc で Apache Ranger を使用する場合のベスト プラクティスを確認する。
- Tableau や Looker などのビジネス インテリジェンス（BI）ツールを使用して、データ アナリスト向けに Dataproc で安全なデータアクセスを設定する方法を確認する。
- オンプレミスの Apache Hadoop システムを Google Cloud に移行する方法を確認する。
- Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティスを確認する。
- リファレンス アーキテクチャ、図、ベスト プラクティスについては、Cloud アーキテクチャ センターをご確認ください。