EMRFS Ranger と Amazon の統合用の S3 プラグイン EMR - Amazon EMR

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

EMRFS Ranger と Amazon の統合用の S3 プラグイン EMR

マルチテナントクラスター上の S3 内のオブジェクトに対するアクセスコントロールを簡単に提供できるように、S3 EMRFS プラグインは、 を介してアクセスするときに S3 内のデータへのアクセスコントロールを提供しますEMRFS。S3 リソースへのアクセスは、ユーザーおよびグループレベルで許可できます。

これを実現するために、アプリケーションが S3 内のデータにアクセスしようとすると、 は認証情報のリクエストをシークレットエージェントプロセスEMRFSに送信し、リクエストは Apache Ranger プラグインに対して認証および承認されます。リクエストが承認されると、シークレットエージェントは制限されたポリシーを持つ Apache Ranger エンジンのIAMロールを引き受け、アクセスを許可した Ranger ポリシーにのみアクセスできる認証情報を生成します。その後、認証情報は EMRFSに戻り、S3 にアクセスします。

サポートされている機能

EMRFS S3 プラグインは、ストレージレベルの認可を提供します。ポリシーを作成して、S3 バケットおよびプレフィックスに対すアクセス権をユーザーおよびグループに提供できます。認証は に対してのみ行われますEMRFS。

サービス設定のインストール

EMRFS サービス定義をインストールするには、Ranger 管理サーバーを設定する必要があります。サーバーをセットアップするには、「」を参照してくださいAmazon と統合するように Ranger 管理サーバーを設定する EMR

EMRFS サービス定義をインストールするには、次の手順に従います。

ステップ 1: Apache Ranger 管理サーバー SSHに入ります

例:

ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal

ステップ 2: EMRFSサービス定義 をダウンロードします

一時ディレクトリで、Amazon EMRサービス定義をダウンロードします。このサービス定義は Ranger 2.x バージョンでサポートされています。

wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-emrfs.json

ステップ 3: EMRFS S3 サービス定義 を登録する

curl -u *<admin users login>*:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-emrfs.json \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ -k 'https://*<RANGER SERVER ADDRESS>*:6182/service/public/v2/api/servicedef'

このコマンドが正常に実行されると、次のイメージに示すように、Ranger 管理 UI にAMAZONEMR「-S3」という新しいサービスが表示されます (Ranger バージョン 2.0 が表示されます)。

Ranger Admin は S3 EMRFS サービスを作成します。

ステップ 4: アプリケーションのインスタンス AMAZON-EMR-EMRFSを作成します

サービス定義のインスタンスを作成します。

  • の横にある をクリックします AMAZON-EMR-EMRFS。

以下のフィールドに入力します。

[Service Name] (サービス名) (表示されている場合): 推奨値は amazonemrspark です。EMR セキュリティ設定を作成するときに必要になるため、このサービス名に注意してください。

[Display Name] (表示名): このサービスに対して表示する名前。推奨値は amazonemrspark です。

[Common Name For Certificate] (証明書の共通名): クライアントプラグインから管理サーバーに接続するために使用する証明書内の CN フィールド。この値は、プラグイン用に作成されたTLS証明書の CN フィールドと一致する必要があります。

Ranger Admin 編集 EMRFS S3 サービス。
注記

このプラグインのTLS証明書は、Ranger 管理サーバーの信頼ストアに登録されている必要があります。詳細については、「TLS Apache Ranger と Amazon の統合の証明書 EMR」を参照してください。

サービスが作成されると、次の図に示すように、Service Manager にはAMAZONEMR「-EMRFS」が含まれます。

新しい S3 EMRFS サービスを表示する Ranger 管理者。

S3 EMRFS ポリシーの作成

新しいポリシーを作成するには、Service Manager の [ポリシーの作成] ページで、次のフィールドに入力します。

[Policy Name] (ポリシー名): このポリシーの名前。

[Policy Label] (ポリシーラベル): このポリシーにつけることができるラベル。

[S3 Resource] (S3 リソース): バケットとオプションのプレフィックスで始まるリソース。ベストプラクティスについては、「EMRFS S3 ポリシーの使用に関する注意事項」を参照してください。Ranger 管理サーバーのリソースには、s3://s3a://s3n:// が含まれていてはいけません。

S3 EMRFS サービスの作成ポリシーを示す Ranger 管理者。

アクセス許可を付与するユーザーおよびグループを指定できます。[許可] 条件および [拒否] 条件の除外を指定することもできます。

S3 EMRFS ポリシーのユーザー/グループのアクセス許可を示す Ranger 管理者。
注記

各ポリシーには最大 3 つのリソースを使用できます。このポリシーをEMRクラスターで使用すると、3 つ以上のリソースを追加するとエラーが発生する可能性があります。3 つを超えるポリシーを追加すると、ポリシーの制限に関するリマインダーが表示されます。

EMRFS S3 ポリシーの使用に関する注意事項

Apache Ranger で S3 ポリシーを作成する際には、いくつかの使用上の考慮事項があります。

複数の S3 オブジェクトへのアクセス許可

再帰ポリシーとワイルドカード式を使用して、共通のプレフィックスを持つ複数の S3 オブジェクトに対するアクセス許可を付与できます。再帰ポリシーは、共通のプレフィックスを持つすべてのオブジェクトに対するアクセス許可を付与します。ワイルドカード式では、複数のプレフィクスが選択されます。これらを組み合わせて、次の例に示されているように、複数の共通のプレフィックスを持つすべてのオブジェクトに対するアクセス許可を付与します。

例 再帰ポリシーを使用する

以下のように整理された S3 バケット内のすべての parquet ファイルをリストするためのアクセス許可が必要であるものとします。

s3://sales-reports/americas/ +- year=2000 | +- data-q1.parquet | +- data-q2.parquet +- year=2019 | +- data-q1.json | +- data-q2.json | +- data-q3.json | +- data-q4.json | +- year=2020 | +- data-q1.parquet | +- data-q2.parquet | +- data-q3.parquet | +- data-q4.parquet | +- annual-summary.parquet +- year=2021

まず、プレフィックス s3://sales-reports/americas/year=2000 の付いた parquet ファイルについて考えます。これらすべてのアクセスGetObject 許可は、次の 2 つの方法で付与できます。

非再帰ポリシーを使用する: 1 つのオプションとして、2 つの別々の非再帰ポリシー (1 つはディレクトリ用、もう 1 つはファイル用) を使用できます。

最初のポリシーでは、プレフィックス s3://sales-reports/americas/year=2020 (末尾に / はありません) に対するアクセス許可を付与します。

- S3 resource = "sales-reports/americas/year=2000" - permission = "GetObject" - user = "analyst"

2 番目のポリシーでは、ワイルドカード式を使用して、プレフィックス sales-reports/americas/year=2020/ (末尾の / に注意) を持つすべてのファイルに対するアクセス許可を付与します。

- S3 resource = "sales-reports/americas/year=2020/*" - permission = "GetObject" - user = "analyst"

再帰ポリシーを使用する: より便利な代替方法として、単一の再帰ポリシーを使用し、プレフィックスに再帰的なアクセス許可を付与できます。

- S3 resource = "sales-reports/americas/year=2020" - permission = "GetObject" - user = "analyst" - is recursive = "True"

これまでのところ、プレフィックス s3://sales-reports/americas/year=2000 の付いた parquet ファイルのみが含まれています。ここで、次のようにワイルドカード式を導入することで、別のプレフィックス s3://sales-reports/americas/year=2020 が付いた parquet ファイルも同じ再帰ポリシーに含めることができます。

- S3 resource = "sales-reports/americas/year=20?0" - permission = "GetObject" - user = "analyst" - is recursive = "True"

PutObject および DeleteObject アクセス許可のポリシー

のファイルに対するポリシーPutObjectDeleteObjectアクセス許可の書き込みには特別な注意EMRFSが必要です。これは、アクセス許可とは異なり GetObject、プレフィックスに付与された追加の再帰アクセス許可が必要なためです。

例 PutObject および DeleteObject アクセス許可のポリシー

例えば、ファイルを削除するannual-summary.parquet場合、実際のファイルに対する DeleteObject アクセス許可だけでなく、

- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet" - permission = "DeleteObject" - user = "analyst"

プレフィックスに対する再帰的な GetObject および PutObject アクセス許可を付与するポリシーも必要になります。

同様に、ファイル annual-summary.parquet を修正するために必要となるのも、実際のファイルに対する PutObject アクセス許可だけではありません。

- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet" - permission = "PutObject" - user = "analyst"

プレフィックスに対する再帰的な GetObject アクセス許可を付与するポリシーも必要になります。

- S3 resource = "sales-reports/americas/year=2020" - permission = "GetObject" - user = "analyst" - is recursive = "True"

ポリシー内のワイルドカード

ワイルドカードを指定できる領域は 2 つあります。S3 リソースを指定するときには、「*」と「?」を使用できます。「*」は S3 パスに対するマッチングを提供し、プレフィクスの後のすべてのものに一致します。ポリシーの例を次に示します。

S3 resource = "sales-reports/americas/*"

これは次の S3 パスと一致します。

sales-reports/americas/year=2020/ sales-reports/americas/year=2019/ sales-reports/americas/year=2019/month=12/day=1/afile.parquet sales-reports/americas/year=2018/month=6/day=1/afile.parquet sales-reports/americas/year=2017/afile.parquet

ワイルドカード「?」は、1 文字にのみ一致します。ポリシーの例を次に示します。

S3 resource = "sales-reports/americas/year=201?/"

これは次の S3 パスと一致します。

sales-reports/americas/year=2019/ sales-reports/americas/year=2018/ sales-reports/americas/year=2017/

ユーザー内のワイルドカード

ユーザーにアクセス権を提供するためにユーザーを割り当てるときには、2 つの組み込みのワイルドカードを使用できます。1 つ目は、すべてのユーザーにアクセス権を提供する「{USER}」ワイルドカードです。2 番目のワイルドカードは「{OWNER}」で、特定のオブジェクトの所有者に直接アクセスできます。ただし、「{USER}」ワイルドカードは現在サポートされていません。

制限事項

EMRFS S3 プラグインの現在の制限は次のとおりです。

  • Apache Ranger ポリシーには、最大 3 つのポリシーを設定できます。

  • S3 へのアクセスは を通じて行う必要がありEMRFS、Hadoop 関連のアプリケーションで使用できます。以下はサポートされていません。

    - Boto3 ライブラリ

    - AWS SDK および AWK CLI

    - S3A オープンソースコネクタ

  • Apache Ranger 拒否ポリシーはサポートされていません。

  • CSE-KMS 暗号化を持つキーを使用した S3 でのオペレーションは現在サポートされていません。

  • クロスリージョンサポートはサポートされていません。

  • Apache Ranger のセキュリティゾーン機能はサポートされていません。セキュリティゾーン機能を使用して定義されたアクセスコントロールの制限は、Amazon EMRクラスターには適用されません。

  • Hadoop は常にEC2インスタンスプロファイルにアクセスするため、Hadoop ユーザーは監査イベントを生成しません。

  • Amazon EMR Consistency View を無効にすることをお勧めします。S3 は強固な整合性を備えているため、これは不要です。詳細については、「Amazon S3 strong consistency」を参照してください。

  • EMRFS S3 プラグインは多数のSTS呼び出しを行います。開発アカウントでロードテストを行い、STS通話量をモニタリングすることをお勧めします。また、サービス制限の引き上げ AssumeRoleをSTSリクエストすることをお勧めします。

  • Ranger 管理サーバーは自動完了をサポートしていません。