翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EMR と Apache Ranger の統合用 EMRFS S3 プラグイン
マルチテナントクラスター上の S3 内のオブジェクトに対するアクセスコントロールを容易に提供できるようにするために、EMRFS S3 プラグインは、EMRFS 経由で S3 内のデータにアクセスするときに S3 内のデータへのアクセスコントロールを提供します。S3 リソースへのアクセスは、ユーザーおよびグループレベルで許可できます。
これを実現するために、アプリケーションが S3 内のデータにアクセスしようとすると、EMRFS は認証情報のリクエストをシークレットエージェントプロセスに送信し、そこでリクエストが Apache Ranger プラグインに対して認証され、認可されます。リクエストが認可されると、シークレットエージェントは制限されたポリシーを使用して Apache Ranger エンジンの IAM ロールを引き受けて、アクセスを許可した Ranger ポリシーにのみアクセスできる認証情報を生成します。その後、その認証情報が EMRFS に戻され、S3 にアクセスできるようになります。
**Topics**
+ [サポートされている機能](#emr-ranger-emrfs-features)
+ [サービス設定のインストール](#emr-ranger-emrfs-service-config)
+ [EMRFS S3 ポリシーの作成](#emr-ranger-emrfs-create-policies)
+ [EMRFS S3 ポリシーの使用に関する注意事項](#emr-ranger-emrfs-considerations)
+ [制限事項](#emr-ranger-emrfs-limitations)
## サポートされている機能
EMRFS S3 プラグインは、ストレージレベルの認可を提供します。ポリシーを作成して、S3 バケットおよびプレフィックスに対すアクセス権をユーザーおよびグループに提供できます。認可は EMRFS に対してのみ行われます。
## サービス設定のインストール
EMRFS サービス定義をインストールするには、Ranger 管理サーバーを設定する必要があります。サーバーをセットアップするには、「[Amazon EMR と統合するように Ranger 管理サーバーを設定する](emr-ranger-admin.md)」を参照してください。
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 **:*_<_**_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://**:6182/service/public/v2/api/servicedef'
```
このコマンドが正常に実行されると、次の図に示すように、Ranger 管理 UI に「AMAZON-EMR-S3」という新しいサービスが表示されます (Ranger バージョン 2.0 が示されています)。
![\[Ranger 管理の EMRFS S3 サービス作成。\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/images/ranger-create-service-EMRFS.png)
**ステップ 4: AMAZON-EMR-EMRFS アプリケーションのインスタンスを作成する**。
サービス定義のインスタンスを作成します。
+ AMAZON-EMR-EMRFS の横の **[\$1]** をクリックします。
以下のフィールドに入力します。
**[Service Name]** (サービス名) (表示されている場合): 推奨値は **amazonemrs3** です。このサービス名をメモしておいてください。EMR セキュリティ設定を作成するときに必要になります。
**[Display Name]** (表示名): このサービスに対して表示する名前。推奨値は **amazonemrs3** です。
**[Common Name For Certificate]** (証明書の共通名): クライアントプラグインから管理サーバーに接続するために使用する証明書内の CN フィールド。この値は、プラグイン用に作成された TLS 証明書の CN フィールドと一致する必要があります。
![\[Ranger 管理の EMRFS S3 サービスの編集。\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/images/ranger-edit-service-EMRFS.png)
**注記**
このプラグインの TLS 証明書は、Ranger 管理サーバーのトラストストアに登録されている必要があります。詳細については、「[Apache Ranger と Amazon EMR の統合のための TLS 証明書](emr-ranger-admin-tls.md)」を参照してください。
サービスが作成されると、次の図に示すように、サービスマネージャーに「AMAZON-EMR-EMRFS」が表示されます。
![\[新しい EMRFS S3 サービスを示す Ranger 管理。\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/images/ranger-new-service-EMRFS.png)
## EMRFS S3 ポリシーの作成
新しいポリシーを作成するには、Service Manager の **[ポリシーの作成]** ページで、次のフィールドに入力します。
**[Policy Name]** (ポリシー名): このポリシーの名前。
**[Policy Label]** (ポリシーラベル): このポリシーにつけることができるラベル。
**[S3 Resource]** (S3 リソース): バケットとオプションのプレフィックスで始まるリソース。ベストプラクティスについては、「[EMRFS S3 ポリシーの使用に関する注意事項](#emr-ranger-emrfs-considerations)」を参照してください。Ranger 管理サーバーのリソースには、**s3://**、**s3a://**、**s3n://** が含まれていてはいけません。
![\[EMRFS S3 サービスのポリシーの作成を示している Ranger 管理。\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/images/ranger-create-policy-EMRFS.png)
アクセス許可を付与するユーザーおよびグループを指定できます。**[許可]** 条件および **[拒否]** 条件の除外を指定することもできます。
![\[EMRFS S3 ポリシーのユーザー/グループのアクセス許可を表示する Ranger 管理。\]](http://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/images/ranger-permissions-EMRFS.png)
**注記**
各ポリシーには最大 3 つのリソースを使用できます。3 つを超えるリソースを追加した場合、このポリシーを EMR クラスターで使用すると、エラーが発生することがあります。3 つを超えるポリシーを追加すると、ポリシーの制限に関するリマインダーが表示されます。
## EMRFS S3 ポリシーの使用に関する注意事項
Apache Ranger で S3 ポリシーを作成する際には、いくつかの使用上の考慮事項があります。
### 複数の S3 オブジェクトへのアクセス許可
再帰ポリシーとワイルドカード式を使用して、共通のプレフィックスを持つ複数の S3 オブジェクトに対するアクセス許可を付与できます。再帰ポリシーは、共通のプレフィックスを持つすべてのオブジェクトに対するアクセス許可を付与します。ワイルドカード式では、複数のプレフィクスが選択されます。これらを組み合わせて、次の例に示されているように、複数の共通のプレフィックスを持つすべてのオブジェクトに対するアクセス許可を付与します。
**Example 再帰ポリシーを使用する**
以下のように整理された 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 ファイルについて考えます。次の 2 つの方法で、それらのすべてに対する GetObject アクセス許可を付与できます。
**非再帰ポリシーを使用する**: 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 アクセス許可のポリシー
EMRFS 上のファイルへの `PutObject` および `DeleteObject` アクセス許可のポリシーを作成する際には、特別な注意が必要です。GetObject アクセス許可とは異なり、プレフィックスに追加の再帰的なアクセス許可を付与する必要があるからです。
**Example 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 リソースを指定するときには、「\$1」と「?」を使用できます。「\$1」は 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 つ目は、すべてのユーザーにアクセス権を提供する「\$1USER\$1」ワイルドカードです。2 番目のワイルドカードは「\$1OWNER\$1」です。これは、特定のオブジェクトまたはディレクトリの所有者にアクセス権を提供します。ただし、「\$1USER\$1」ワイルドカードは現在サポートされていません。
## 制限事項
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 整合性ビューを無効にすることをお勧めします。S3 は強固な整合性を備えているため、これは不要です。詳細については、「[Amazon S3 strong consistency](https://aws.amazon.com/s3/consistency/)」を参照してください。
+ EMRFS S3 プラグインは多数の STS 呼び出しを行います。開発アカウントで負荷テストを行い、STS 呼び出しボリュームをモニタリングすることをお勧めします。また、AssumeRole サービスの制限を引き上げる STS リクエストを行うことをお勧めします。
+ Ranger 管理サーバーはオートコンプリートをサポートしていません。