翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon EKS アクセスエントリ認証 Amazon EKS は、クラスターの Kubernetes API を呼び出すアクセス許可を IAM プリンシパルに付与するための 2 つのメカニズムをサポートしています。レガシー `aws-auth` ConfigMap と新しい[アクセスエントリ API](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) です。アクセスエントリは、いずれかのメカニズムを通じてクラスターに対して認証できる ConfigMap. AWS Batch can を編集しなくても、KubernetesAPI アクセスを IAM プリンシパルに付与します。 コンピューティング環境で `eksConfiguration.accessEntry.desiredState`を に設定する`ENABLED`と、 はクラスター上のそのコンピューティング環境のアクセスエントリを管理 AWS Batch できます。ConfigMap `aws-auth` を手動で編集する必要がなくなりました。 がアクセスエントリを AWS Batch プロビジョニングするかどうかは、 AWS Batch コンピューティング環境と Amazon EKS クラスター設定によって異なります。詳細については、「[クラスターの とのやり取り `authenticationMode`](#eks-access-entries-matrix)」を参照してください。 ## `accessEntry.desiredState` の値 の `desiredState`フィールドは、コンピューティング環境に必要なアクセスエントリの状態を`EksAccessEntry`宣言します。次の値を指定できます。 `ENABLED` AWS Batch は、コンピューティング環境の AWS Batchマネージドアクセスエントリをクラスターに作成します。 AWS Batch は、クラスター上のすべてのコンピューティング環境が `desiredState` に設定されている場合にのみ、 AWS Batchマネージドアクセスエントリを作成します `ENABLED` (詳細については、[がコンピューティング環境`desiredState`間で AWS Batch 調整する方法](#eks-access-entries-reconciliation)「」を参照）。 `DISABLED` AWS Batch は、クラスター AWS Batchのマネージドアクセスエントリを削除します。 AWS Batch は、クラスター上のすべてのコンピューティング環境が `desiredState` に設定されている場合にのみ AWS Batch、マネージドアクセスエントリを削除します `DISABLED` (詳細については、[がコンピューティング環境`desiredState`間で AWS Batch 調整する方法](#eks-access-entries-reconciliation)「」を参照）。クラスターへのアクセスは、ConfigMap `aws-auth` を介して設定する必要があります。 `INHERIT_FROM_CLUSTER` AWS Batch は、クラスターの現在のアクセスエントリ に延期します`status`。認証モードが である Amazon EKS クラスターでは`API`、クラスターにフォールバックする `aws-auth` ConfigMap がないため、 はアクセスエントリ AWS Batch を作成および管理します。認証モードが `CONFIG_MAP`または のクラスターでは`API_AND_CONFIG_MAP`、 はアクセスエントリを追加または削除 AWS Batch しません。 コンピューティング環境では、[DescribeComputeEnvironments](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeComputeEnvironments.html) レスポンスの読み取り専用`accessEntry.status`フィールドも公開されます。 `ACTIVE` は、コンピューティング環境の AWS Batchマネージドアクセスエントリがクラスターに存在し、ConfigMap `aws-auth` よりも優先されることを意味します。 は AWS Batch、マネージドアクセスエントリが存在しない`INACTIVE`ことを意味します。これは、 `desiredState`が であるため`DISABLED`、クラスターをターゲットとするコンピューティング環境がまだ に同意していないため`desiredState`、またはエントリがまだプロビジョニングされていないためです。`accessEntry.status` が の場合`INACTIVE`、Batch はクラスターアクセスに `aws-auth` ConfigMap を使用します。 **注記** アクセスエントリは、 AWS Batch が使用可能にするアクセスポリシーの関連付けを完了していない場合でも、クラスターに存在すると`ACTIVE`すぐにレポートします。が の`INVALID`ときにコンピューティング環境のステータス`accessEntry.status`が に変わる場合は`ACTIVE`、「」を参照してください[Amazon EKS アクセスエントリの設定が不完全です](batch_eks_invalid_compute_environment.md#batch_eks_access_entry_incomplete)。 **注記** `accessEntry` フィールドを省略した場合、 AWS Batch はコンピューティング環境`desiredState`の を記録せず、 `DescribeComputeEnvironments`は を返しません。アクセスエントリをプロビジョニングする目的で、 は と同じように AWS Batch 動作します`INHERIT_FROM_CLUSTER`。 ## クラスターの とのやり取り `authenticationMode` 特定の の動作 AWS Batch は、クラスターの認証モード`desiredState`によって異なります。次の表は、 `CreateComputeEnvironment`と の両方に適用されます`UpdateComputeEnvironment`。
クラスター authenticationModeコンピューティング環境 accessEntry.desiredState=ENABLEDコンピューティング環境 accessEntry.desiredState=DISABLEDコンピューティング環境 accessEntry.desiredState=INHERIT_FROM_CLUSTER
CONFIG_MAPアクセスエントリはクラスターで使用できないため、 AWS Batch はアクセスエントリを作成または削除しません。 AWS Batch は、指定した値を記録します。クラスターの認証モードを変更すると、その記録された値は、 を指定する次の CreateComputeEnvironmentまたは UpdateComputeEnvironment呼び出しで有効になりますdesiredState。
API_AND_CONFIG_MAPAWS Batch は、クラスターを共有するコンピューティング環境全体で記録された値を比較します。「」を参照してくださいがコンピューティング環境`desiredState`間で AWS Batch 調整する方法。既存のアクセスモードは保持されます。 アクセスエントリを追加または削除 AWS Batch しません。
APIアクセスエントリはクラスターで作成および維持されます。リクエストは却下されました。このモードのクラスターは ConfigMap aws-auth をサポートしておらず、クラスターの作成後に ConfigMap メソッドを有効にすることができないため、 DISABLED はコンピューティング環境を離れて認証を行うことはできません。アクセスエントリはクラスターで作成および維持されます。クラスターが APIのみの場合、継承は と同等ですENABLED。
## がコンピューティング環境`desiredState`間で AWS Batch 調整する方法 単一の Amazon EKS クラスターは複数の AWS Batch コンピューティング環境をバックアップできるため、クラスターのアクセス設定は共有リソースです。 AWS Batch したがって、 はそれらのコンピューティング環境全体で記録された`desiredState`値を調整または比較して解決します。 クラスターの `authenticationMode`が の場合`API_AND_CONFIG_MAP`、 はクラスターをターゲットとする同じ AWS アカウントと AWS リージョン内のすべてのコンピューティング環境について`desiredState`記録された AWS Batch を比較します。 はこの比較 AWS Batch を使用して、 を指定する各 `CreateComputeEnvironment` または `UpdateComputeEnvironment`オペレーションでアクセスエントリを追加または削除するかどうかを決定します`desiredState`。 すべてのコンピューティング環境には `desiredState=ENABLED` AWS Batch はクラスターにアクセスエントリを作成します。 すべてのコンピューティング環境には `desiredState=DISABLED` AWS Batch は、アクセスエントリが存在する場合、クラスターからアクセスエントリを削除します。 記録された`desiredState`値がすべて一致するわけではありません AWS Batch は既存のアクセスモードを保持します。アクセスエントリは追加も削除もされません。これには、`ENABLED`、、`DISABLED`および の任意の組み合わせが含まれ`INHERIT_FROM_CLUSTER`、`desiredState`記録されていないコンピューティング環境も含まれます。 **注記** 認証モードが ConfigMap `aws-auth` `API_AND_CONFIG_MAP`であるクラスターをエントリ認証に移行するには、クラスターをターゲットとする`desiredState=ENABLED`すべての AWS Batch コンピューティング環境で を設定します。元に戻すには、それぞれ`desiredState=DISABLED`に を設定します。 ## がクラスターに AWS Batch 作成する内容 AWS Batch は、上記の条件を満たすクラスターごとに 1 つのアクセスエントリを作成し、`AWSBatchClusterPolicy`Amazon EKS アクセスポリシーをそのアクセスエントリに関連付けます。アクセスエントリはコンピューティング環境ごとではなくクラスターごとであるため、同じクラスターをターゲットとするすべての AWS Batch コンピューティング環境で共有されます。 **注記** コンピューティング環境を削除しても、クラスター上の最後の AWS Batch コンピューティング環境であっても、アクセスエントリは削除されません。 AWS Batchマネージドアクセスエントリを削除するには、クラスターをターゲットとするすべての AWS Batch コンピューティング環境で `UpdateComputeEnvironment``desiredState=DISABLED`と を呼び出してから、クラスターを削除します。 アクセスエントリだけでは、クラスターでジョブを実行するのに十分ではありません。自分で設定する必要があるKubernetesアクセス許可とノードアクセスについては、「」を参照してください[それでも提供する必要があるクラスター設定](#eks-access-entries-additional-configuration)。 ## 必要なアクセス許可 AWS Batch は、 `CreateComputeEnvironment`または `UpdateComputeEnvironment`オペレーションを呼び出す IAM ID の認証情報を使用してアクセスエントリを管理します。この ID は、次の Amazon EKS アクションを実行することを許可されている必要があります。 + `eks:DescribeCluster` + `eks:DescribeAccessEntry` + `eks:CreateAccessEntry` + `eks:AssociateAccessPolicy` + `eks:DeleteAccessEntry` ## アクセスエントリを設定する [CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html) API または [UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html) API の `eksConfiguration.accessEntry`フィールドを使用して、コンピューティング環境でアクセスエントリを設定できます。 ------ #### [ AWS CLI ] **コンピューティング環境の作成時に AWS Batchマネージドアクセスエントリを有効にする** ``` $ aws batch create-compute-environment \ --compute-environment-name {{my-eks-ce}} \ --type MANAGED \ --eks-configuration 'eksClusterArn={{arn:aws:eks:us-east-1:123456789012:cluster/my-cluster}},kubernetesNamespace={{my-aws-batch-namespace}},accessEntry={desiredState=ENABLED}' \ --compute-resources 'type=EC2,maxvCpus=128,subnets={{subnet-a123456b}},securityGroupIds={{sg-a12b3456}},instanceRole={{arn:aws:iam::123456789012:instance-profile/my-node-instance-profile}}' ``` **既存のコンピューティング環境で AWS Batchマネージドアクセスエントリを有効にする** ``` $ aws batch update-compute-environment \ --compute-environment {{my-eks-ce}} \ --eks-configuration 'accessEntry={desiredState=ENABLED}' ``` **ステータスを確認する** ``` $ aws batch describe-compute-environments \ --compute-environments {{my-eks-ce}} \ --query "computeEnvironments[0].eksConfiguration.accessEntry" ``` レスポンスには`desiredState`、指定した と観測された の両方が含まれます`status`。 ``` { "desiredState": "ENABLED", "status": "ACTIVE" } ``` **注記** AWS Batch はすべての Amazon EKS コンピューティング環境`accessEntry.status`に対して を返し、設定した`desiredState`場合にのみ を返します。指定したことがないコンピューティング環境は、`status`単独で `accessEntry` を返します。 アクセスエントリ AWS Batch の管理を停止するには、`DISABLED`代わりに `desiredState`を に設定します。確認する前に、認証モードが であるクラスターでは [クラスターの とのやり取り `authenticationMode`](#eks-access-entries-matrix): `DISABLED`が拒否され`API`、認証モードが`API_AND_CONFIG_MAP`アクセスエントリであるクラスターでは、クラスターをターゲットとするすべての AWS Batch コンピューティング環境が に設定された後にのみ削除されます`DISABLED`。 ------ #### [ API ] [CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html) または [UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html) リクエストで `eksConfiguration.accessEntry` オブジェクトを使用します。 ** AWS Batchマネージドアクセスエントリを使用してコンピューティング環境を作成する** リクエスト本文`accessEntry`に を含めます。 ``` { "computeEnvironmentName": "{{my-eks-ce}}", "type": "MANAGED", "state": "ENABLED", "eksConfiguration": { "eksClusterArn": "{{arn:aws:eks:us-east-1:123456789012:cluster/my-cluster}}", "kubernetesNamespace": "{{my-aws-batch-namespace}}", "accessEntry": { "desiredState": "ENABLED" } }, "computeResources": { "type": "EC2", "maxvCpus": 128, "subnets": ["{{subnet-a123456b}}"], "securityGroupIds": ["{{sg-a12b3456}}"], "instanceRole": "{{arn:aws:iam::123456789012:instance-profile/my-node-instance-profile}}" } } ``` **既存のコンピューティング環境のアクセスエントリを更新する** ``` { "computeEnvironment": "{{my-eks-ce}}", "eksConfiguration": { "accessEntry": { "desiredState": "ENABLED" } } } ``` 詳細については、 *AWS Batch API リファレンス*の[`EksAccessEntry`](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksAccessEntry.html)「」、[CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html)」、および[UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)」を参照してください。 ------ ## それでも提供する必要があるクラスター設定 アクセスエントリは、 がクラスターに対して AWS Batch 認証する方法のみを制御します。ジョブの実行に必要な AWS Batch Kubernetesアクセス許可は付与されず、 AWS Batch 起動するインスタンスはクラスターに参加しません。使用する認証メカニズムにかかわらず、以下の両方を設定する必要があります。 **重要** クラスター (`accessEntry.status=ACTIVE`) AWS Batch のサービスにリンクされたロールの AWS Batchマネージドアクセスエントリが作成されると、ロールの ConfigMap `aws-auth` 設定よりも優先されます。 AWS Batch サービスにリンクされたロールの ConfigMap エントリは使用されず、代わりに アクセスエントリを使用して AWS Batch 認証されます。ConfigMap 認証に戻るには、クラスターをターゲットとする`desiredState=DISABLED`すべてのコンピューティング環境で を設定します。これにより、 AWS Batchマネージドアクセスエントリが削除されます。 Kubernetes AWS Batch 名前空間の アクセス許可 AWS Batch には、 で指定した名前空間でポッドを作成および管理するためのKubernetesアクセス許可が必要です`eksConfiguration.kubernetesNamespace`。名前空間を作成し、認証アプローチに応じて次のいずれかの方法を使用してこれらのアクセス許可を設定します。 + **アクセスポリシーの関連付け (アクセスエントリ の場合に必須`status=ACTIVE`)** — クラスターをターゲット`desiredState=ENABLED`とするすべてのコンピューティング環境で を設定すると、 はクラスターレベルの を使用してアクセスエントリ AWS Batch を作成します`AWSBatchClusterPolicy`。次に、名前空間スコープを関連付け`AWSBatchNamespacePolicy`て、ポッドを作成および管理するためのアクセス許可を付与 AWS Batch する必要があります。 アクセスエントリが に達したら`status=ACTIVE`、以下を使用して名前空間ポリシーを関連付けます AWS CLI。 ``` $ aws eks associate-access-policy \ --cluster-name {{my-cluster}} \ --principal-arn {{arn:aws:iam::123456789012:role/aws-service-role/batch.amazonaws.com/AWSServiceRoleForBatch}} \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AWSBatchNamespacePolicy \ --access-scope type=namespace,namespaces={{my-aws-batch-namespace}} ``` {{my-aws-batch-namespace}} を で指定した値に置き換えます`eksConfiguration.kubernetesNamespace`。 **重要** 名前空間スコープポリシーの関連付けがないと、ジョブは`RUNNABLE`ステータスのままになります。クラスターレベルのポリシーだけでは、ポッド管理アクセス許可は付与されません。 + **Kubernetes ロールとロールバインディング (アクセスエントリ の場合`status=INACTIVE`)** — マネージドアクセスエントリがアクティブでない場合は、 AWS Batch「」で説明されているように、これらのアクセス許可を付与するロールKubernetesとロールバインディングを作成します[ステップ 2: 用の Amazon EKS クラスターを準備する AWS Batch](getting-started-eks.md#getting-started-eks-step-1)。これはクラスターごとに 1 回行います。 **注記** AWS Batchマネージドアクセスエントリがアクティブな場合 (`status=ACTIVE`)、KubernetesRBAC ロールはバイパスされます。代わりに、アクセスポリシーの関連付け方法を使用する必要があります。 AWS Batch はこれらのリソースを作成しません。また、 AWS Batchマネージドアクセスエントリがリソースの代わりになることはありません。それらが見つからない場合、ジョブの開始に失敗`VALID`してもコンピューティング環境は になる可能性があります。 ノードインスタンスロールのクラスターアクセス AWS Batch を起動するインスタンスは、 で指定したインスタンスプロファイルを使用してクラスターに参加します`computeResources.instanceRole`。このロールには、 AWS Batchが管理するアクセスエントリとは別のクラスターへの独自のアクセスが必要であり、 AWS Batch は設定しません。 設定方法は、クラスターの によって異なります`authenticationMode`。 + **`authenticationMode` が のクラスター`CONFIG_MAP`**の場合 — ConfigMap `aws-auth` を使用する必要があります。アクセスエントリは、これらのクラスターではサポートされていません。 + **`authenticationMode` が のクラスター`API_AND_CONFIG_MAP`**の場合 — ノードインスタンスロールは、ConfigMap `aws-auth` またはアクセスエントリを使用して認証できます。インスタンスロールが ConfigMap に既にマッピングされている場合、ノードはロールのアクセスエントリを作成せずに正常に結合されます。 + **`authenticationMode` が のクラスター`API`**の場合 — ノードインスタンスロールのアクセスエントリを作成する必要があります。ConfigMap `aws-auth` は、これらのクラスターでの認証には使用されません。 ノードインスタンスロールのアクセスエントリを作成するには、以下を使用します AWS CLI。 ``` $ aws eks create-access-entry \ --cluster-name {{my-cluster}} \ --principal-arn {{arn:aws:iam::123456789012:role/my-node-instance-role}} \ --type EC2_LINUX ``` ``` $ aws eks associate-access-policy \ --cluster-name {{my-cluster}} \ --principal-arn {{arn:aws:iam::123456789012:role/my-node-instance-role}} \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSWorkerNodePolicy \ --access-scope type=cluster ``` 詳細については、**「Amazon EKS ユーザーガイド**」の[「アクセスエントリの作成](https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html)」を参照してください。 ノードインスタンスロールに適切なクラスターアクセスがないと、EC2 インスタンスはクラスターに参加できません。クラスターにキャパシティーが登録されないため、ジョブは `RUNNABLE`状態のままになります。 ## ConfigMap `aws-auth` エントリとアクセスエントリの選択 アクセスエントリ認証は、Amazon EKS コンピューティング環境の新しい AWS Batch に推奨されるパスであり、次の利点があります。 + ConfigMap `aws-auth` を手動で編集してクラスター AWS Batch へのアクセスを許可する必要がなくなります。 + クラスターにアクセスできるプリンシパルの監査可能な API 駆動型レコードを提供します。 + ConfigMap をサポートしていない `authenticationMode`が `aws-auth` `API`であるクラスターに必要です。 クラスターの `authenticationMode`が の場合`CONFIG_MAP`、アクセスエントリは利用できず、ConfigMap `aws-auth` を介して AWS Batch 認証されます。手順については、「[`aws-auth ConfigMap` のフィールドが正しく設定されていることを確認します](verify-configmap-config.md)」を参照してください。