翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon EMR で IAM が機能する仕組み
IAM を使用して Amazon EMR へのアクセスを管理する前に、Amazon EMR で使用できる IAM 機能について理解しておく必要があります。
Amazon EMR で使用できる IAM の機能 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
IAM 機能 | Amazon EMR サポート | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Yes |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Yes |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
なし |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
はい |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
いいえ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
あり |
Amazon EMR およびその他の AWS のサービスがほとんどの IAM 機能と連携する方法の概要を把握するには、「IAM ユーザーガイド」のAWS 「IAM と連携する のサービス」を参照してください。
Amazon EMR の ID ベースのポリシー
アイデンティティベースポリシーをサポートする |
あり |
アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースのポリシーを作成する方法については、IAM ユーザーガイドのIAM ポリシーの作成を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。プリンシパルは、それが添付されているユーザーまたはロールに適用されるため、アイデンティティベースのポリシーでは指定できません。JSON ポリシーで使用できるすべての要素について学ぶには、IAM ユーザーガイドのIAM JSON ポリシーの要素のリファレンスを参照してください。
Amazon EMR の ID ベースのポリシーの例
Amazon EMR のアイデンティティベースポリシーの例を確認するには、「Amazon EMR のアイデンティティベースポリシーの例」を参照してください。
Amazon EMR 内のリソースベースのポリシー
リソースベースのポリシーのサポート |
あり |
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM ロールの信頼ポリシー や Amazon S3 バケットポリシー があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーでは、プリンシパルを指定する必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS のサービス。
クロスアカウントアクセスを有効にするには、アカウント全体、または別のアカウントの IAM エンティティをリソースベースのポリシーのプリンシパルとして指定します。リソースベースのポリシーにクロスアカウントのプリンシパルを追加しても、信頼関係は半分しか確立されない点に注意してください。プリンシパルとリソースが異なる にある場合 AWS アカウント、信頼されたアカウントの IAM 管理者は、プリンシパルエンティティ (ユーザーまたはロール) にリソースへのアクセス許可も付与する必要があります。IAM 管理者は、アイデンティティベースのポリシーをエンティティにアタッチすることで権限を付与します。ただし、リソースベースのポリシーで、同じアカウントのプリンシパルへのアクセス権が付与されている場合は、アイデンティティベースのポリシーをさらに付与する必要はありません。詳細については、「IAM ユーザーガイド」の「IAM でのクロスアカウントリソースアクセス」を参照してください。
Amazon EMR のポリシーアクション
ポリシーアクションに対するサポート |
あり |
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどんなリソースにどんな条件でアクションを実行できるかということです。
JSON ポリシーのAction
要素には、ポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。ポリシーアクションの名前は通常、関連付けられた AWS API オペレーションと同じです。一致する API オペレーションのない許可のみのアクションなど、いくつかの例外があります。また、ポリシーに複数のアクションが必要なオペレーションもあります。これらの追加アクションは、依存アクションと呼ばれます。
このアクションは、関連付けられたオペレーションを実行するための権限を付与するポリシーで使用されます。
Amazon EMR のアクションのリストについては、「サービス認証リファレンス」の「Amazon EMR のアクション、リソース、および条件キー」を参照してください。
Amazon EMR のポリシーアクションは、アクションの前に次のプレフィックスを使用します。
EMR
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
"Action": [ "EMR:
action1
", "EMR:action2
" ]
Amazon EMR のアイデンティティベースポリシーの例を確認するには、「Amazon EMR のアイデンティティベースポリシーの例」を参照してください。
Amazon EMR のポリシーリソース
ポリシーリソースに対するサポート |
あり |
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースにどのような条件でアクションを実行できるかということです。
Resource
JSON ポリシー要素は、アクションが適用されるオブジェクトを指定します。ステートメントには、Resource
または NotResource
要素を含める必要があります。ベストプラクティスとして、Amazon リソースネーム (ARN) を使用してリソースを指定します。これは、リソースレベルの許可と呼ばれる特定のリソースタイプをサポートするアクションに対して実行できます。
オペレーションのリスト化など、リソースレベルの権限をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (*) を使用します。
"Resource": "*"
Amazon EMR リソースのタイプとその ARN のリストについては、「サービス認証リファレンス」の「Resources Defined by Amazon EMR」を参照してください。各リソースの ARN を指定できるアクションについては、「Actions, resources, and condition keys for Amazon EMR」を参照してください。
Amazon EMR のアイデンティティベースポリシーの例を確認するには、「Amazon EMR のアイデンティティベースポリシーの例」を参照してください。
Amazon EMR のポリシー条件キー
サービス固有のポリシー条件キーのサポート |
あり |
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどんなリソースにどんな条件でアクションを実行できるかということです。
Condition
要素 (または Condition
ブロック) を使用すると、ステートメントが有効な条件を指定できます。Condition
要素はオプションです。イコールや未満などの 条件演算子 を使用して条件式を作成することで、ポリシーの条件とリクエスト内の値を一致させることができます。
1 つのステートメントに複数の Condition
要素を指定する場合、または 1 つの Condition
要素に複数のキーを指定する場合、 AWS では AND
論理演算子を使用してそれらを評価します。1 つの条件キーに複数の値を指定すると、 は論理OR
オペレーションを使用して条件 AWS を評価します。ステートメントの権限が付与される前にすべての条件が満たされる必要があります。
条件を指定する際にプレースホルダー変数も使用できます。例えば IAM ユーザーに、IAM ユーザー名がタグ付けされている場合のみリソースにアクセスできる権限を付与することができます。詳細については、IAM ユーザーガイドのIAM ポリシーの要素: 変数およびタグを参照してください。
AWS は、グローバル条件キーとサービス固有の条件キーをサポートします。すべての AWS グローバル条件キーを確認するには、「IAM ユーザーガイド」のAWS 「 グローバル条件コンテキストキー」を参照してください。
Amazon EMR の条件キーのリスト、および条件キーを使用できるアクションとリソースについては、「サービス認証リファレンス」の「Actions, resources, and condition keys for Amazon EMR」を参照してください。
Amazon EMR のアイデンティティベースポリシーの例を確認するには、「Amazon EMR のアイデンティティベースポリシーの例」を参照してください。
Amazon EMR のアクセスコントロールリスト (ACL)
ACL のサポート |
なし |
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするための許可を持つかをコントロールします。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
Amazon EMR での属性ベースのアクセスコントロール (ABAC)
ABAC のサポート (ポリシー内のタグ) | はい |
属性ベースのアクセス制御 (ABAC) は、属性に基づいてアクセス許可を定義するアクセス許可戦略です。では AWS、これらの属性はタグ と呼ばれます。タグは、IAM エンティティ (ユーザーまたはロール) および多くの AWS リソースにアタッチできます。エンティティとリソースのタグ付けは、ABAC の最初の手順です。その後、プリンシパルのタグがアクセスしようとしているリソースのタグと一致した場合にオペレーションを許可するように ABAC ポリシーをします。
ABAC は、急成長する環境やポリシー管理が煩雑になる状況で役立ちます。
タグに基づいてアクセスを管理するには、aws:ResourceTag/
、key-name
aws:RequestTag/
、または key-name
aws:TagKeys
の条件キーを使用して、ポリシーの 条件要素でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値はありです。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「部分的」になります。
ABAC の詳細については、IAM ユーザーガイドのABAC とは?を参照してください。ABAC をセットアップするステップを説明するチュートリアルについては、IAM ユーザーガイドの属性に基づくアクセスコントロール (ABAC) を使用するを参照してください。
Amazon EMR での一時認証情報の使用
一時的な認証情報のサポート |
あり |
一部の は、一時的な認証情報を使用してサインインすると機能 AWS のサービス しません。一時的な認証情報 AWS のサービス を使用する などの詳細については、IAM ユーザーガイドのAWS のサービス 「IAM と連携する 」を参照してください。
ユーザー名とパスワード以外の AWS Management Console 方法で にサインインする場合、一時的な認証情報を使用します。例えば、会社の Single Sign-On (SSO) リンク AWS を使用して にアクセスすると、そのプロセスによって一時的な認証情報が自動的に作成されます。また、ユーザーとしてコンソールにサインインしてからロールを切り替える場合も、一時的な認証情報が自動的に作成されます。ロールの切り替えに関する詳細については、IAM ユーザーガイドのロールへの切り替え (コンソール)を参照してください。
一時的な認証情報は、 AWS CLI または AWS API を使用して手動で作成できます。その後、これらの一時的な認証情報を使用して . AWS recommends にアクセスできます AWS。これは、長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成することを推奨しています。詳細については、IAM の一時的セキュリティ認証情報を参照してください。
Amazon EMR のクロスサービスプリンシパルのアクセス許可
フォワードアクセスセッション (FAS) をサポート |
あり |
IAM ユーザーまたはロールを使用して でアクションを実行すると AWS、プリンシパルと見なされます。一部のサービスを使用する際に、アクションを実行することで、別のサービスの別のアクションがトリガーされることがあります。FAS は、 を呼び出すプリンシパルのアクセス許可を AWS のサービス、ダウンストリームサービス AWS のサービス へのリクエストのリクエストと組み合わせて使用します。FAS リクエストは、サービスが他の AWS のサービス またはリソースとのやり取りを完了する必要があるリクエストを受け取った場合にのみ行われます。この場合、両方のアクションを実行するためのアクセス許可が必要です。FAS リクエストを行う際のポリシーの詳細については、「転送アクセスセッション」を参照してください。
Amazon EMR のサービスロール
サービスロールのサポート | なし |
Amazon EMR のサービスリンクロール
サービスリンクロールのサポート | あり |
サービスリンクロールの作成または管理の詳細については、IAM と提携するAWS
のサービスを参照してください。表の中から、[Service-linked role] (サービスにリンクされたロール) 列に Yes
と記載されたサービスを見つけます。サービスリンクロールに関するドキュメントをサービスで表示するには、はい リンクを選択します。
IAM ポリシーを持つクラスターとノートブックのタグをアクセスコントロールに使用する
EMR Notebooks および EMR クラスターに関連した Amazon EMR アクションに対する許可は、アイデンティティベースの IAM ポリシーを用いたタグベースのアクセスコントロールを使用して調整できます。ノートブック、クラスター、またはその両方に特定のタグキーまたはキーと値の組み合わせがある場合にのみ特定のアクションを許可するには、Condition
要素 (Condition
ブロックとも呼ばれる) 内で条件キーを使用できます。CreateEditor
アクション (EMR Notebooks が作成される)、RunJobFlow
アクション (クラスターが作成される) を制限することもできます。これにより、タグに対するリクエストが、リソースの作成時に送信されなければならないようにすることができます。
Amazon EMR では、Condition
要素で使用できる条件キーは、リクエストパラメータとして ClusterID
または NotebookID
を必要とする Amazon EMR API アクションにのみ適用されます。例えば、 ModifyInstanceGroupsアクションは、 ClusterID
がオプションのパラメータであるため、コンテキストキーをサポートしていません。
EMR ノートブックを作成すると、デフォルトのタグが適用されます。このタグのキー文字列は creatorUserId
で、ノートブックを作成した IAM ユーザー ID の値に設定されています。ノートブックに対して許可されるアクションを作成者のみに制限するのに便利です。
Amazon EMR で次の条件キーを使用できます。
-
elasticmapreduce:ResourceTag/
条件コンテキストキーを使用して、指定したTagKeyString
のあるタグを持つクラスターまたはノートブックのユーザーアクションを許可または拒否します。TagKeyString
ClusterID
とNotebookID
の両方を渡す場合、条件がクラスターとノートブッククラスターの両方に適用されます。つまり、両方のリソースに、タグキー文字または指定するキーと値の組み合わせが必要です。Resource
要素を使用してステートメントを制限できるため、必要に応じてクラスターまたはノートブックにのみ適用されます。詳細については、「Amazon EMR のアイデンティティベースポリシーの例」を参照してください。 -
アクション/API コールを持つ特定のタグを必要としている
elasticmapreduce:RequestTag/
条件コンテキストキーを使用します。たとえば、この条件コンテキストキーとともにTagKeyString
CreateEditor
アクションを使用して、
を持つキーがノートブック作成時に適用されるよう要求することができます。TagKeyString
例
Amazon EMR アクションのリストを確認するには、「IAM ユーザーガイド」の「Amazon EMR で定義されるアクション」を参照してください。