Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Authentification des entrées d'accès Amazon EKS Amazon EKS prend en charge deux mécanismes pour accorder à un IAM principal l'autorisation d'appeler l'KubernetesAPI du cluster : l'ancienne `aws-auth` ConfigMap et la nouvelle API [ d'entrée d'](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)accès. Une entrée d'accès permet d'accéder à l'KubernetesAPI à un principal IAM sans que vous ayez à modifier un ConfigMap. AWS Batch peut s'authentifier auprès de votre cluster via l'un ou l'autre des mécanismes. Lorsque vous définissez `eksConfiguration.accessEntry.desiredState` `ENABLED` sur un environnement de calcul, vous AWS Batch pouvez gérer l'entrée d'accès pour cet environnement de calcul sur le cluster. Vous n'avez plus besoin de modifier manuellement le `aws-auth` ConfigMap. Le AWS Batch provisionnement d'une entrée d'accès dépend de votre environnement AWS Batch informatique et de la configuration de votre cluster Amazon EKS. Consultez [Interaction avec le mode d'`authentification du cluster`](#eks-access-entries-matrix) pour plus de détails. ## Valeurs d'`accès Entry.desiredState` Le `desiredState` champ sur `EksAccessEntry` déclare l'état d'entrée d'accès souhaité pour l'environnement informatique. Les valeurs valides sont : `ENABLED` AWS Batch crée une entrée d'accès AWS Batch gérée sur le cluster pour l'environnement informatique. AWS Batch ne créera une entrée d'accès AWS Batch gérée que si tous les environnements de calcul du cluster sont définis `desiredState` sur `ENABLED` (voir [Comment ? AWS Batch réconcilie `DesiredState entre` les environnements informatiques](#eks-access-entries-reconciliation) pour plus de détails). `DISABLED` AWS Batch supprime l'entrée d'accès AWS Batch-managed pour le cluster. AWS Batch supprimera une entrée d'accès AWS Batch géré uniquement si tous les environnements de calcul du cluster sont définis `desiredState` sur `DISABLED` (voir [Comment ? AWS Batch réconcilie `DesiredState entre` les environnements informatiques](#eks-access-entries-reconciliation) pour plus de détails). L'accès au cluster doit être configuré via le `aws-auth` ConfigMap. `INHERIT_FROM_CLUSTER` AWS Batch s'en remet à l'entrée `status` d'accès actuelle du cluster. Sur un cluster Amazon EKS dont le mode d'authentification est`API`, AWS Batch crée et gère une entrée d'accès car le cluster n'a pas d'accès `aws-auth` ConfigMap vers lequel se rabattre. Sur un cluster dont le mode d'authentification est `CONFIG_MAP` ou`API_AND_CONFIG_MAP`, AWS Batch aucune entrée d'accès n'est ajoutée ni supprimée. L'environnement informatique expose également un `accessEntry.status` champ en lecture seule dans les réponses. [ DescribeComputeEnvironments ](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeComputeEnvironments.html) `ACTIVE`signifie qu'une entrée d'accès AWS Batch gérée pour l'environnement informatique existe sur le cluster et a priorité sur. `aws-auth` ConfigMap `INACTIVE`signifie qu'aucune entrée AWS Batch d'accès gérée n'est présente. Cela peut être dû au `desiredState` fait `DISABLED` que les environnements de calcul ciblant le cluster ne sont pas encore d'accord`desiredState`, ou au fait que l'entrée n'a pas encore été provisionnée. Si `accessEntry.status` c'est le cas`INACTIVE`, Batch l'utilise `aws-auth` ConfigMap pour l'accès au cluster. **Note** Une entrée d'accès signale `ACTIVE` dès qu'elle existe sur le cluster, même si elle AWS Batch n'a pas fini d'associer la politique d'accès qui la rend utilisable. Si l'état de l'environnement de calcul passe à `INVALID` while `accessEntry.status` is`ACTIVE`, consultez[La configuration des entrées d'accès Amazon EKS est incomplète](batch_eks_invalid_compute_environment.md#batch_eks_access_entry_incomplete). **Note** Si vous omettez le `accessEntry` champ, AWS Batch aucune valeur n'est enregistrée `desiredState` pour l'environnement informatique et `DescribeComputeEnvironments` n'en renvoie aucune. Aux fins de provisionnement de l'entrée d'accès, AWS Batch se comporte comme pour. `INHERIT_FROM_CLUSTER` ## Interaction avec le mode d'`authentification du cluster` Le AWS Batch comportement d'un cluster donné `desiredState` dépend du mode d'authentification du cluster. Le tableau suivant s'applique à la fois à `CreateComputeEnvironment` et`UpdateComputeEnvironment`.
Cluster authenticationModeEnvironnement informatique accessEntry.desiredState=ENABLEDEnvironnement informatique accessEntry.desiredState=DISABLEDEnvironnement informatique accessEntry.desiredState=INHERIT_FROM_CLUSTER
CONFIG_MAPLes entrées d'accès ne sont pas disponibles sur le cluster, il AWS Batch n'est donc pas possible d'en créer ni d'en supprimer. AWS Batch enregistre toujours la valeur que vous spécifiez. Une fois que vous avez modifié le mode d'authentification du cluster, cette valeur enregistrée prend effet lors de votre prochain UpdateComputeEnvironment appel CreateComputeEnvironment ou de l'appel qui le spécifiedesiredState.
API_AND_CONFIG_MAPAWS Batch compare les valeurs enregistrées dans les environnements informatiques qui partagent le cluster — voirComment ? AWS Batch réconcilie `DesiredState entre` les environnements informatiques.Le mode d'accès existant est conservé. AWS Batch n'ajoute ni ne supprime aucune entrée d'accès.
APIL'entrée d'accès est créée et gérée sur le cluster.La demande est rejetée. Dans ce mode, un cluster ne prend pas en charge le aws-auth ConfigMap, et la ConfigMap méthode ne peut pas être activée après la création du cluster, ce qui DISABLED laisserait l'environnement de calcul sans aucun moyen de s'authentifier.L'entrée d'accès est créée et gérée sur le cluster. Lorsque le cluster est uniquement composé de API -only, hériter est équivalent à. ENABLED
## Comment ? AWS Batch réconcilie `DesiredState entre` les environnements informatiques Étant donné qu'un seul cluster Amazon EKS peut gérer plusieurs environnements de AWS Batch calcul, la configuration d'accès d'un cluster est une ressource partagée. AWS Batch réconcilie donc, ou compare et résout, les `desiredState` valeurs enregistrées dans ces environnements informatiques. Lorsque le cluster `authenticationMode` est`API_AND_CONFIG_MAP`, AWS Batch compare les données `desiredState` enregistrées pour chaque environnement informatique du même AWS compte et de la même AWS région qui cible le cluster. AWS Batch utilise cette comparaison pour déterminer s'il faut ajouter ou supprimer l'entrée d'accès pour chaque `CreateComputeEnvironment` `UpdateComputeEnvironment` opération spécifiée`desiredState`. Chaque environnement informatique possède `desiredState=ENABLED` AWS Batch crée l'entrée d'accès sur le cluster. Chaque environnement informatique possède `desiredState=DISABLED` AWS Batch supprime l'entrée d'accès du cluster, s'il en existe une. Les `desiredState` valeurs enregistrées ne correspondent pas toutes AWS Batch conserve le mode d'accès existant. L'entrée d'accès n'est ni ajoutée ni supprimée. Cela inclut toute combinaison de `ENABLED``DISABLED`, et`INHERIT_FROM_CLUSTER`, et cela inclut également tout environnement informatique qui n'a aucun `desiredState` enregistrement. **Note** Pour faire passer un cluster dont le mode d'authentification passe `API_AND_CONFIG_MAP` de l'authentification par entrée d'accès `aws-auth` ConfigMap à l'authentification par entrée, configurez `desiredState=ENABLED` chaque environnement AWS Batch informatique qui cible le cluster. Pour revenir en arrière, `desiredState=DISABLED` optez pour chacun d'eux. ## Quoi AWS Batch crée sur votre cluster AWS Batch crée une entrée d'accès par cluster qui répond aux conditions ci-dessus, puis associe la politique d'accès `AWSBatchClusterPolicy` Amazon EKS à cette entrée d'accès. L'entrée d'accès se fait par cluster plutôt que par environnement de calcul, de sorte que tous les environnements de AWS Batch calcul qui ciblent le même cluster la partagent. **Note** La suppression d'un environnement de calcul ne supprime pas l'entrée d'accès, même s'il s'agit du dernier environnement de AWS Batch calcul du cluster. Pour supprimer une entrée d'accès AWS Batch gérée, appelez `UpdateComputeEnvironment` with `desiredState=DISABLED` sur chaque environnement de AWS Batch calcul qui cible le cluster avant de le supprimer. Une entrée d'accès ne suffit pas à elle seule pour exécuter des tâches sur le cluster. Pour les Kubernetes autorisations et l'accès aux nœuds que vous devez configurer vous-même, consultez[Configuration de cluster que vous devez toujours fournir](#eks-access-entries-additional-configuration). ## Autorisations requises AWS Batch gère l'entrée d'accès à l'aide des informations d'identification de l'identité IAM qui appelle l'`UpdateComputeEnvironment`opération `CreateComputeEnvironment` ou. Cette identité doit être autorisée à effectuer les actions Amazon EKS suivantes : + `eks:DescribeCluster` + `eks:DescribeAccessEntry` + `eks:CreateAccessEntry` + `eks:AssociateAccessPolicy` + `eks:DeleteAccessEntry` ## Configuration de l'entrée d'accès Vous pouvez configurer l'entrée d'accès sur un environnement informatique via le `eksConfiguration.accessEntry` champ de l'[UpdateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html)API [ CreateComputeEnvironment ](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html) or. ------ #### [ AWS CLI ] **Activer une entrée d'accès AWS Batch gérée lors de la création d'un environnement informatique ** ``` $ 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}}' ``` **Activer une entrée d'accès AWS Batch gérée sur un environnement informatique existant ** ``` $ aws batch update-compute-environment \ --compute-environment {{my-eks-ce}} \ --eks-configuration 'accessEntry={desiredState=ENABLED}' ``` **Vérifiez le statut ** ``` $ aws batch describe-compute-environments \ --compute-environments {{my-eks-ce}} \ --query "computeEnvironments[0].eksConfiguration.accessEntry" ``` La réponse inclut à la fois `desiredState` ce que vous avez spécifié et ce qui a été observé `status` : ``` { "desiredState": "ENABLED", "status": "ACTIVE" } ``` **Note** AWS Batch renvoie `accessEntry.status` pour tous les environnements de calcul Amazon EKS, et `desiredState` ne renvoie que si vous l'avez défini. Un environnement informatique dans lequel vous ne spécifiez jamais `status` uniquement les `accessEntry` retours. Pour arrêter AWS Batch de gérer l'entrée d'accès, définissez `DISABLED` plutôt `desiredState` sur. Avant de le faire, vérifiez [Interaction avec le mode d'`authentification du cluster`](#eks-access-entries-matrix) : `DISABLED` est rejeté sur un cluster dont le mode d'authentification est`API`, et sur un cluster dont le mode d'authentification est, `API_AND_CONFIG_MAP` l'entrée d'accès n'est supprimée qu'une fois que chaque environnement de AWS Batch calcul qui cible le cluster est défini sur`DISABLED`. ------ #### [ API ] Utilisez l'`eksConfiguration.accessEntry`objet de votre [ UpdateComputeEnvironment ](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html) demande [ CreateComputeEnvironment ](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html) ou de votre demande. **Création d'un environnement informatique avec une AWS Batch entrée d'accès gérée ** Inclure `accessEntry` dans le corps de la demande : ``` { "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}}" } } ``` **Mettre à jour l'entrée d'accès sur un environnement informatique existant ** ``` { "computeEnvironment": "{{my-eks-ce}}", "eksConfiguration": { "accessEntry": { "desiredState": "ENABLED" } } } ``` Pour plus d'informations, consultez [`EksAccessEntry`](https://docs.aws.amazon.com/batch/latest/APIReference/API_EksAccessEntry.html) [ CreateComputeEnvironment](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateComputeEnvironment.html), et [ UpdateComputeEnvironment ](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateComputeEnvironment.html) dans la référence de l'*AWS Batch API*. ------ ## Configuration de cluster que vous devez toujours fournir Une entrée d'accès contrôle uniquement la manière dont vous vous AWS Batch authentifiez auprès de votre cluster. Il n'accorde pas AWS Batch les Kubernetes autorisations dont il a besoin pour exécuter vos tâches et ne permet pas aux instances qui se AWS Batch lancent de rejoindre le cluster. Quel que soit le mécanisme d'authentification que vous utilisez, vous devez toujours configurer les deux options suivantes. **Important** Une fois qu'une entrée d'accès AWS Batch géré est créée pour le rôle AWS Batch lié à un service sur un cluster (`accessEntry.status=ACTIVE`), elle a priorité sur la `aws-auth` ConfigMap configuration du rôle. Les ConfigMap entrées du rôle AWS Batch lié à un service ne sont pas utilisées et AWS Batch s'authentifie à l'aide de l'entrée d'accès à la place. Pour revenir à ConfigMap l'authentification, configurez tous `desiredState=DISABLED` les environnements de calcul qui ciblent le cluster. Cela supprime l'entrée d'accès AWS Batch-managed. Kubernetesautorisations pour l'espace de AWS Batch noms AWS Batch a besoin d'Kubernetesautorisations pour créer et gérer des pods dans l'espace de noms que vous spécifiez dans`eksConfiguration.kubernetesNamespace`. Créez l'espace de noms, puis configurez ces autorisations à l'aide de l'une des méthodes suivantes en fonction de votre approche d'authentification : + **Association de règles d'accès (obligatoire lors de la saisie d'accès`status=ACTIVE`) ** : lorsque vous configurez `desiredState=ENABLED` tous les environnements de calcul ciblant un cluster, AWS Batch crée une entrée d'accès au niveau du cluster`AWSBatchClusterPolicy`. Vous devez ensuite associer le namespace-scoped `AWSBatchNamespacePolicy` pour AWS Batch autoriser la création et la gestion des pods. Une fois l'entrée d'accès atteinte`status=ACTIVE`, associez la politique d'espace de noms à l'aide de 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}}Remplacez-la par la valeur que vous avez spécifiée dans`eksConfiguration.kubernetesNamespace`. **Important** Sans l'association de politiques à l'échelle de l'espace de noms, le statut des emplois restera bloqué. `RUNNABLE` La politique au niveau du cluster à elle seule n'accorde pas d'autorisations de gestion des pods. + **Kubernetesrôles et liaisons de rôles (lors de l'entrée d'accès`status=INACTIVE`) ** : si l'entrée d'accès AWS Batch gérée n'est pas active, créez les Kubernetes rôles et les liaisons de rôles qui accordent ces autorisations, comme décrit dans. [Étape 2 : Préparez votre cluster Amazon EKS pour AWS Batch](getting-started-eks.md#getting-started-eks-step-1) Vous effectuez cette opération une fois pour chaque cluster. **Note** Lorsqu'une entrée d'accès AWS Batch gérée par -managed est active (`status=ACTIVE`), les rôles Kubernetes RBAC sont contournés. Vous devez plutôt utiliser la méthode d'association de politiques d'accès. AWS Batch ne crée pas ces ressources pour vous, et une entrée d'accès AWS Batch géré ne s'y substitue pas. S'ils sont absents, l'environnement informatique peut continuer à fonctionner même `VALID` si vos tâches ne démarrent pas. Accès au cluster pour le rôle d'instance de nœud Les instances qui sont AWS Batch lancées rejoignent le cluster à l'aide du profil d'instance que vous spécifiez dans`computeResources.instanceRole`. Ce rôle a besoin de son propre accès au cluster, qui est distinct de l'entrée d'accès AWS Batch-managed et qui AWS Batch ne se configure pas. La méthode de configuration dépend de celle de votre cluster `authenticationMode` : + **Sur les clusters `authenticationMode` dont `CONFIG_MAP` ** — Vous devez utiliser le `aws-auth` ConfigMap. Les entrées d'accès ne sont pas prises en charge sur ces clusters. + **Sur les clusters dont le rôle `authenticationMode` est `API_AND_CONFIG_MAP` ** : le rôle d'instance de nœud peut s'authentifier à l'aide de l'entrée `aws-auth` ConfigMap ou d'une entrée d'accès. Si le rôle d'instance est déjà mappé dans le ConfigMap, les nœuds se joindront avec succès sans créer d'entrée d'accès pour le rôle. + **Sur les clusters dont `authenticationMode` c'est le cas `API` ** : vous devez créer une entrée d'accès pour le rôle d'instance de nœud. Le n'`aws-auth` ConfigMap est pas utilisé pour l'authentification sur ces clusters. Pour créer une entrée d'accès pour le rôle d'instance de nœud, utilisez 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 ``` Pour plus d'informations, consultez la section [ Création d'entrées d'accès ](https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html) dans le guide de l'utilisateur * * Amazon EKS **. Sans accès approprié au cluster pour le rôle d'instance de nœud, les instances EC2 ne peuvent pas rejoindre le cluster. Les emplois resteront dans l'`RUNNABLE`État car aucune capacité n'est enregistrée auprès du cluster. ## Choisir entre les entrées `aws-auth et Access` ConfigMap L'authentification des entrées d'accès est le chemin recommandé pour AWS Batch les nouveaux environnements de calcul Amazon EKS, et elle offre les avantages suivants : + Il n'est pas nécessaire de modifier manuellement le `aws-auth` ConfigMap pour autoriser l' AWS Batch accès au cluster. + Fournit un API-driven enregistrement vérifiable des principaux utilisateurs qui ont accès au cluster. + Est obligatoire pour les clusters dont `authenticationMode` c'est le cas `API` et qui ne prennent pas en charge le `aws-auth` ConfigMap. Si c'`authenticationMode`est le cas de votre cluster`CONFIG_MAP`, les entrées d'accès ne sont pas disponibles et AWS Batch s'authentifie via le `aws-auth` ConfigMap. Pour obtenir des instructions, consultez [Vérifiez que l'`aws-auth est correctement configuré ConfigMap`](verify-configmap-config.md).