Amazon EMR で IAM が機能する仕組み
IAM を使用して Amazon EMR へのアクセスを管理する前に、Amazon EMR で使用できる IAM 機能について理解しておく必要があります。
Amazon EMR で使用できる IAM の機能 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
IAM 機能 | Amazon EMR サポート | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
はい |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Yes |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
はい |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
はい |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
はい |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
いいえ |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Yes |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
はい |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
はい |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
No | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Yes |
Amazon EMR およびその他の AWS サービスと大部分の IAM 機能との連携に関する概要については、「IAM ユーザーガイド」の「IAM と連携する AWS のサービス」を参照してください。
Amazon EMR の ID ベースのポリシー
アイデンティティベースのポリシーのサポート |
はい |
アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーを作成する方法については、「IAM ユーザーガイド」の「IAM ポリシーの作成」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、アクションを許可または拒否する条件を指定できます。プリンシパルは、それが添付されているユーザーまたはロールに適用されるため、アイデンティティベースのポリシーでは指定できません。JSON ポリシーで使用できるすべての要素について学ぶには、「IAM ユーザーガイド」の「IAM JSON ポリシーの要素のリファレンス」を参照してください。
Amazon EMR の ID ベースのポリシーの例
Amazon EMR のアイデンティティベースポリシーの例を確認するには、「Amazon EMR のアイデンティティベースポリシーの例」を参照してください。
Amazon EMR 内のリソースベースのポリシー
リソースベースのポリシーのサポート |
Yes |
リソースベースのポリシーは、リソースにアタッチする JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM ロールの信頼ポリシーや Amazon S3 バケットポリシーがあげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。ポリシーが添付されているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、プリンシパルを指定する必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または AWS のサービス を含めることができます。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。リソースベースのポリシーにクロスアカウントのプリンシパルを追加しても、信頼関係は半分しか確立されない点に注意してください。プリンシパルとリソースが異なる AWS アカウント にある場合、信頼できるアカウントの IAM 管理者は、リソースにアクセスするための許可をプリンシパルエンティティ (ユーザーまたはロール) に付与する必要もあります。IAM 管理者は、アイデンティティベースのポリシーをエンティティにアタッチすることで許可を付与します。ただし、リソースベースのポリシーで、同じアカウントのプリンシパルへのアクセス権が付与されている場合は、ID ベースのポリシーをさらに付与する必要はありません。詳細については、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 のポリシー条件キー
サービス固有のポリシー条件キーのサポート |
Yes |
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースに対してどのような条件下でアクションを実行できるかということです。
Condition
要素 (または Condition
ブロック) を使用すると、ステートメントが有効な条件を指定できます。Condition
要素はオプションです。イコールや未満などの条件演算子を使用して条件式を作成することで、ポリシーの条件とリクエスト内の値を一致させることができます。
1 つのステートメントに複数の Condition
要素を指定する場合、または 1 つの Condition
要素に複数のキーを指定する場合、AWS では AND
論理演算子を使用してそれらを評価します。単一の条件キーに複数の値を指定する場合、AWS では OR
論理演算子を使用して条件を評価します。ステートメントの許可が付与される前にすべての条件が満たされる必要があります。
条件を指定する際にプレースホルダー変数も使用できます。例えば 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 (ポリシー内のタグ) のサポート | Yes |
属性ベースのアクセス制御 (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 ユーザーガイドの「IAM と連携する AWS のサービス」を参照してください。
ユーザー名とパスワード以外の方法で AWS Management Console にサインインする場合は、一時認証情報を使用していることになります。例えば、会社の Single Sign-On (SSO) リンクを使用して AWS にアクセスすると、そのプロセスは自動的に一時認証情報を作成します。また、ユーザーとしてコンソールにサインインしてからロールを切り替える場合も、一時認証情報が自動的に作成されます。ロールの切り替えに関する詳細については、IAM ユーザーガイドの「ロールへの切り替え (コンソール)」を参照してください。
一時認証情報は、AWS CLI または AWS API を使用して手動で作成できます。作成後、一時認証情報を使用して AWS にアクセスできるようになります。AWS は、長期的なアクセスキーを使用する代わりに、一時認証情報を動的に生成することをお勧めします。詳細については、「IAM の一時的セキュリティ認証情報」を参照してください。
Amazon EMR のクロスサービスプリンシパルのアクセス許可
プリンシパル許可のサポート |
はい |
IAM ユーザーまたはロールを使用して AWS でアクションを実行するユーザーは、プリンシパルと見なされます。ポリシーは、プリンシパルにアクセス許可を付与します。一部のサービスを使用する際に、アクションを実行することで、別のサービスの別のアクションがトリガーされることがあります。この場合、両方のアクションを実行するための許可が必要です。アクションがポリシーで追加の依存アクションを必要とするかどうかを確認するには、「サービス認証リファレンス」の「Actions, Resources, and Condition Keys for Amazon EMR」を参照してください。
Amazon EMR のサービスロール
サービスロールに対するサポート | No |
Amazon EMR のサービスリンクロール
サービスにリンクされたロールのサポート | Yes |
サービスにリンクされたロールの作成または管理の詳細については、IAM と提携する AWS のサービス」を参照してください。表の中から、[Service-linked role] (サービスにリンクされたロール) 列に Yes
と記載されたサービスを見つけます。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、[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 で定義されるアクション」を参照してください。