**このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# Amazon EKS の Identity and Access Management
<a name="security-iam"></a>

 AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するのに役立つ AWS のサービスです。IAM 管理者は、誰の (サインイン) を*認証*し、誰による Amazon EKS リソースの使用を*承認する* (アクセス許可を付与する) かを制御します。IAM は、AWS のサービスで追加料金は発生しません。

## オーディエンス
<a name="security-iam-audience"></a>

AWS Identity and Access Management (IAM) の使用方法は、Amazon EKS で行う作業によって異なります。

 **サービスユーザー** – ジョブを実行するために Amazon EKS サービスを使用する場合は、管理者から必要なアクセス許可と認証情報が与えられます。さらに多くの Amazon EKS 機能を使用して作業を行う場合は、追加のアクセス許可が必要になることがあります。アクセスの管理方法を理解すると、管理者から適切なアクセス許可をリクエストするのに役に立ちます。Amazon EKS の機能にアクセスできない場合は、「[IAM のトラブルシューティング](security-iam-troubleshoot.md)」を参照してください。

 **サービス管理者** – 社内の Amazon EKS リソースを管理しているユーザーには、通常、Amazon EKS への完全なアクセス権限があります。サービスのユーザーがどの Amazon EKS 機能やリソースにアクセスするかを決めるのは管理者の仕事です。その後、IAM 管理者にリクエストを送信して、サービスユーザーの権限を変更する必要があります。このページの情報を確認して、IAM の基本概念を理解してください。企業が Amazon EKS で IAM を利用する方法については、「[アマゾン EKS で IAM を使用する方法](security-iam-service-with-iam.md)」を参照してください。

 **IAM 管理者** – IAM 管理者には、Amazon EKS へのアクセスを管理するポリシーの作成方法を、詳細に把握する必要が生じる場合があります。IAM で使用可能な、Amazon EKS アイデンティティベースのポリシーの例を確認するには、「[Amazon EKS でのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。

## アイデンティティを使用した認証
<a name="security-iam-authentication"></a>

認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、AWS アカウントのルートユーザーもしくは IAM ユーザーとして、または IAM ロールを引き受けることによって、*認証を受ける* (AWS にサインインする) 必要があります。

ID ソースから提供された認証情報を使用して、フェデレーティッドアイデンティティとして AWS にサインインできます。AWSフェデレーティッドアイデンティティの例としては、IAM アイデンティティセンター (IAM アイデンティティセンター) ユーザー、貴社のシングルサインオン認証、Google または Facebook の認証情報などがあります。フェデレーティッド ID としてサインインする場合、IAM ロールを使用して、前もって管理者により ID フェデレーションが設定されています。フェデレーションを使用して AWSにアクセスする場合、間接的にロールを引き受けることになります。

ユーザーのタイプに応じて、AWS マネジメントコンソール または AWS アクセスポータルにサインインできます。AWS へのサインインの詳細については、AWS サインインユーザーガイドの「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。

プログラムを使用して AWS にアクセスする場合、AWSは Software Development Kit (SDK) とコマンドラインインターフェイス (CLI) を提供し、認証情報を使用してリクエストに暗号で署名します。AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。リクエストに署名する推奨方法の使用については、「*IAM ユーザーガイド*」の「[AWS API リクエストの署名](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html)」を参照してください。

使用する認証方法を問わず、追加セキュリティ情報の提供をリクエストされる場合もあります。例えば、AWS は、アカウントのセキュリティを強化するために多要素認証 (MFA) を使用することをお勧めします。詳細については、「*AWS IAM Identity Center ユーザーガイド*」の「[多要素認証 (MFA)](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)」および「*IAM ユーザーガイド*」の「[AWS での多要素認証 (MFA) の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)」を参照してください。

### AWS アカウントのルートユーザー
<a name="security-iam-authentication-rootuser"></a>

AWS アカウントを作成する場合は、このアカウントのすべての AWS サービスとリソースに対して完全なアクセス権を持つ 1 つのサインインアイデンティティから始めます。このアイデンティティは AWS アカウント*ルートユーザー*と呼ばれ、アカウントの作成に使用したメールアドレスとパスワードでのサインインによりアクセスされます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー資格情報は保護し、ルートユーザーでしか実行できないタスクを実行するときに使用します。ルートユーザーとしてサインインする必要があるタスクの完全なリストについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。

### IAM ユーザーとグループ
<a name="security-iam-authentication-iamuser"></a>

[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*IAM ユーザー*は、単一のユーザーまたはアプリケーションに対する特定の許可を持つ AWS アカウント内のアイデンティティです。可能であれば、パスワードやアクセスキーなどの長期的な認証情報を保有する IAM ユーザーを作成する代わりに、一時的な認証情報を使用することをお勧めします。ただし、IAM ユーザーでの長期的な認証情報が必要な特定のユースケースがある場合は、アクセスキーをローテーションすることをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[長期的な認証情報を必要とするユースケースのためにアクセスキーを定期的にローテーションする](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials)」を参照してください。

[IAM グループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーのコレクションを指定するアイデンティティです。グループとしてサインインすることはできません。グループを使用して、複数のユーザーに対して一度に権限を指定できます。多数のユーザーグループがある場合、グループを使用することで権限の管理が簡単になります。例えば、*IAMAdmins* という名前のグループを設定して、そのグループに IAM リソースを管理する許可を与えることができます。

ユーザーは、ロールとは異なります。ユーザーは 1 人の人または 1 つのアプリケーションに一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。ユーザーには永続的な長期の認証情報がありますが、ロールでは一時的な認証情報が提供されます。詳細については、「*IAM ユーザーガイド*」の「(ロールではなく) [IAM ユーザーの作成が適している場合](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)」を参照してください。

### IAM ロール
<a name="security-iam-authentication-iamrole"></a>

[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*IAM ロール*は、特定のアクセス許可を持つ、AWS アカウント内のアイデンティティです。これは IAM ユーザーに似ていますが、特定のユーザーに関連付けられていません。[ロールを切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)ことによって、AWS マネジメントコンソールで IAM ロールを一時的に引き受けることができます。ロールを引き受けるには、AWS CLI または AWS API オペレーションを呼び出すか、カスタム URL を使用します。ロールを使用する方法の詳細については、「*IAM ユーザーガイド*」の「[IAM ロールの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html)」を参照してください。

IAM ロールと一時的な認証情報は、次の状況で役立ちます:
+  **フェデレーションユーザーアクセス** – フェデレーティッド ID に許可を割り当てるには、ロールを作成してそのロールの許可を定義します。フェデレーテッド ID が認証されると、その ID はロールに関連付けられ、ロールで定義されている許可が付与されます。フェデレーションの詳細については、「*IAM ユーザーガイド*」の「[サードパーティーアイデンティティプロバイダー向けロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html)」を参照してください。IAM Identity Center を使用する場合は、許可セットを設定します。アイデンティティが認証後にアクセスできるものを制御するため、IAM Identity Center は、権限セットを IAM のロールに関連付けます。アクセス許可セットの詳細については、「*AWS IAM Identity Center ユーザーガイド*」の「[アクセス許可セット](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)」を参照してください。
+  **一時的な IAM ユーザー権限** - IAM ユーザーまたはロールは、特定のタスクに対して複数の異なる権限を一時的に IAM ロールで引き受けることができます。
+  **クロスアカウントアクセス** - IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを、別のアカウントの人物 (信頼済みプリンシパル) に許可できます。ロールは、クロスアカウントアクセスを許可する主な方法です。ただし、一部の AWS のサービスでは、 (ロールをプロキシとして使用する代わりに) リソースにポリシーを直接アタッチできます。クロスアカウントアクセスにおけるロールとリソースベースのポリシーの違いについては、「*IAM ユーザーガイド*」の「[IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)」を参照してください。
+  **クロスサービスアクセス** – 一部の AWS のサービスは、AWS の他のサービスの機能を使用します。例えば、サービスで呼び出しを行うと、通常そのサービスによって Amazon EC2 でアプリケーションが実行されたり、Amazon S3 にオブジェクトが保存されたりします。サービスは、呼び出し元のプリンシパルの許可、サービスロール、サービスリンクロールを使用してこれを行う場合があります。
  +  **転送アクセスセッション (FAS)** – IAM ユーザーまたはロールを使用して AWS でアクションを実行するユーザーは、プリンシパルと見なされます。一部のサービスを使用する際に、アクションを実行することで、別のサービスの別のアクションがトリガーされることがあります。FAS は、AWS サービスを呼び出すプリンシパルの権限を、AWS サービスのリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストは、サービスが、完了するために他の AWS サービスまたはリソースとのやりとりを必要とするリクエストを受け取ったときにのみ行われます。この場合、両方のアクションを実行するためのアクセス許可が必要です。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
  +  **サービスロール** - サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除することができます。詳細については、『*IAM ユーザーガイド*』の「[AWS のサービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。
  +  **サービスリンクロール** – サービスリンクロールは、AWS のサービスにリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
+  **Amazon EC2 で実行されているアプリケーション** – EC2 インスタンスで実行され、AWS CLI または AWS API リクエストを作成しているアプリケーションの一時的な認証情報を管理するには、IAM ロールを使用します。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。AWS ロールを EC2 インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスに添付されたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時的な認証情報を取得できます。詳細については、*IAM ユーザーガイド*の[Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用して許可を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)を参照してください。

IAM ロールと IAM ユーザーのどちらを使用するかについては、*IAM ユーザーガイド*の[(IAM ユーザーではなく) IAM ロールをいつ作成したら良いのか?](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role)を参照してください。

## ポリシーを使用したアクセス権の管理
<a name="security-iam-access-manage"></a>

AWS でアクセスを制御するには、ポリシーを作成して AWS ID またはリソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、プリンシパル (ユーザー、ルートユーザー、またはロールセッション) がリクエストを行うと、これらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWSに保存されます。JSON ポリシードキュメントの構造と内容の詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。

管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。

デフォルトでは、ユーザーやロールに権限はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。その後、管理者はロールに IAM ポリシーを追加し、ユーザーはロール引き継ぐことができます。

IAM ポリシーは、オペレーションの実行方法を問わず、アクションの許可を定義します。例えば、`iam:GetRole` アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からロール情報を取得できます。

### アイデンティティベースポリシー
<a name="security-iam-access-manage-id-based-policies"></a>

アイデンティティベースのポリシーは、IAM ユーザーグループ、ユーザーのグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースのポリシーを作成する方法については、「IAM ユーザーガイド**」の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。

アイデンティティベースのポリシーは、さらに*インラインポリシー*または*マネージドポリシー*に分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれています。管理ポリシーは、AWS アカウント内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンポリシーです。管理ポリシーには、AWS 管理ポリシーとカスタマー管理ポリシーが含まれます。マネージドポリシーまたはインラインポリシーのいずれかを選択する方法については、*IAM ユーザーガイド*の[マネージドポリシーとインラインポリシーの比較](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline)を参照してください。

### リソースベースのポリシー
<a name="security-iam-access-manage-resource-based-policies"></a>

リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[[specify a principal]](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) (プリンシパルを指定する) 必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または AWS のサービスを含めることができます。

リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM からの AWS マネージド型ポリシーを使用することはできません。

### アクセスコントロールリスト (ACL)
<a name="security-iam-access-manage-acl"></a>

アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。

Amazon S3、AWS WAF、および Amazon VPC は、ACL をサポートするサービスの例です。ACL の詳細については、*Amazon Simple Storage Service デベロッパーガイド* の [アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) を参照してください。

### その他のポリシータイプ
<a name="security-iam-access-manage-other-policies"></a>

 AWS では、他の一般的ではないポリシータイプをサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の権限を設定できます。
+  **アクセス許可の境界** - アクセス許可の境界は、アイデンティティベースポリシーによって IAM エンティティ (IAM ユーザーまたはロール) に付与できる権限の上限を設定する高度な機能です。エンティティにアクセス許可の境界を設定できます。結果として得られるアクセス許可は、エンティティのアイデンティティベースポリシーとそのアクセス許可の境界の共通部分になります。`Principal` フィールドでユーザーまたはロールを指定するリソースベースのポリシーでは、アクセス許可の境界は制限されません。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。アクセス許可の境界の詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+  **サービスコントロールポリシー (SCP)** – SCP とは、AWS Organizations 内の組織または組織単位 (OU) に対し、アクセス許可の上限を指定するための JSON ポリシーです。AWSOrganizations は、ビジネスが所有する複数の AWS アカウントを、グループ化および一元管理するためのサービスです。組織内のすべての機能を有効にすると、サービスコントロールポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP はメンバーアカウントのエンティティに対するアクセス許可を制限します (各 AWS アカウントルートユーザーなど)。Organizations と SCP の詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+  **セッションポリシー** - セッションポリシーは、ロールまたはフェデレーションユーザーの一時的なセッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果として得られるセッションの許可は、ユーザーまたはロールのアイデンティティベースポリシーとセッションポリシーの共通部分です。また、リソースベースのポリシーから権限が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。

### 複数のポリシータイプ
<a name="security-iam-access-manage-multiple-policies"></a>

1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、*IAM ユーザーガイド*の[ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)を参照してください。