Créer des entrées d’accès - Amazon EKS
AWS Management ConsoleAWS CLI

Aidez à améliorer cette page

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.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

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.

Créer des entrées d’accès

Avant de créer des entrées d'accès, tenez compte des éléments suivants :

  • Un mode d’authentification correctement configuré. Consultez Modifier le mode d’authentification pour utiliser les entrées d’accès .

  • Une entrée d'accès inclut l'Amazon Resource Name (ARN) d'un et d'un seul principal IAM existant. Un principal IAM ne peut pas être inclus dans plus d’une entrée d’accès. Considérations supplémentaires concernant l'ARN que vous spécifiez :

    • Les bonnes pratiques IAM recommandent d'accéder à votre cluster en utilisant des rôles IAM dotés d'informations d'identification à court terme, plutôt que des utilisateurs IAM dotés d'informations d'identification à long terme. Pour plus d’informations, consultez Exiger que les utilisateurs humains utilisent la fédération avec un fournisseur d’identité pour accéder à AWS à l’aide d’informations d’identification temporaires dans le Guide d’utilisateur IAM.

    • Si l'ARN est destiné à un rôle IAM, il peut inclure un chemin. Les ARN dans les entrées aws-auth ConfigMap ne peuvent pas inclure de chemin. Par exemple, votre ARN peut être arn:aws:iam::<111122223333>:role/<development/apps/my-role> ou arn:aws:iam::<111122223333>:role/<my-role>.

    • Si le type de l’entrée d’accès est différent de STANDARD (voir la considération suivante concernant les types), l’ARN doit appartenir au même compte AWS que celui du cluster. Si le type est STANDARD, l’ARN peut appartenir soit au même compte AWS, soit à un autre compte que celui du cluster.

    • Vous ne pouvez pas modifier le principal IAM après la création de l’entrée d’accès.

    • Si vous supprimez le principal IAM correspondant à cet ARN, l’entrée d’accès n’est pas supprimée automatiquement. Nous vous recommandons de supprimer l'entrée d'accès avec un ARN pour un principal IAM que vous supprimez. Si vous ne supprimez pas l’entrée d’accès et que vous recréez plus tard le principal IAM, même avec le même ARN, l’entrée d’accès ne fonctionnera pas. Cela s’explique par le fait que, bien que l’ARN soit identique pour le principal IAM recréé, le roleID ou le userID (consultable avec la commande AWS CLI aws sts get-caller-identity) du principal IAM recréé est différent de celui du principal IAM d’origine. Même si le roleID ou le userID du principal IAM ne s’affiche pas dans l’entrée d’accès, Amazon EKS le conserve en interne avec l’entrée d’accès.

  • Chaque entrée d’accès possède un type. Le type de l’entrée d’accès dépend du type de ressource associée ; il ne définit pas les autorisations. Si vous ne spécifiez pas de type, Amazon EKS définit automatiquement le type sur STANDARD

    • EC2_LINUX : pour un rôle IAM utilisé avec des nœuds autogérés Linux ou Bottlerocket

    • EC2_WINDOWS : pour un rôle IAM utilisé avec des nœuds autogérés Windows

    • FARGATE_LINUX : pour un rôle IAM utilisé avec AWS Fargate (Fargate)

    • HYBRID_LINUX : pour un rôle IAM utilisé avec des nœuds hybrides

    • STANDARD : type par défaut si aucun n’est spécifié

    • EC2 : pour les classes de nœuds personnalisées du mode automatique EKS. Pour de plus amples informations, consultez Création d’une entrée d’accès pour la classe de nœuds.

    • Vous ne pouvez pas modifier le type après la création de l’entrée d’accès.

  • Il n’est pas nécessaire de créer une entrée d’accès pour un rôle IAM utilisé par un groupe de nœuds géré ou par un profil Fargate. EKS créera des entrées d’accès (si cette option est activée) ou mettra à jour la ConfigMap d’authentification (si les entrées d’accès ne sont pas disponibles)

  • Si le type d'entrée d'accès est STANDARD, vous pouvez spécifier un nom d'utilisateur pour l'entrée d'accès. Si vous ne spécifiez aucune valeur pour le nom d’utilisateur, Amazon EKS en attribue automatiquement une, selon le type d’entrée d’accès et selon que le principal IAM indiqué est un rôle IAM ou un utilisateur IAM. Sauf si vous avez une raison précise de définir votre propre nom d’utilisateur, il est recommandé de ne pas en spécifier et de laisser Amazon EKS le générer automatiquement. Si vous spécifiez votre propre nom d'utilisateur :

    • Il ne peut pas commencer par system:, eks:, aws:, amazon: ou iam:.

    • Si le nom d’utilisateur s’applique à un rôle IAM, il est recommandé d’ajouter {{SessionName}} ou {{SessionNameRaw}} à la fin de votre nom d’utilisateur. Si vous ajoutez {{SessionName}} ou {{SessionNameRaw}} à votre nom d’utilisateur, alors le nom d’utilisateur doit comporter un deux-points avant {{SessionName}}. Lorsque ce rôle est assumé, le nom de la session AWS STS utilisé au moment de l’assumer est automatiquement transmis au cluster et apparaîtra dans les journaux CloudTrail. Par exemple, vous ne pouvez pas avoir le nom d’utilisateur john{{SessionName}}. Le nom d'utilisateur doit être :john{{SessionName}} ou jo:hn{{SessionName}}. Il suffit que les deux-points soient devant {{SessionName}}. Le nom d'utilisateur généré par Amazon EKS dans le tableau suivant inclut un ARN. Comme un ARN inclut les deux-points, il répond à cette exigence. Le deux-points n’est pas requis si vous n’incluez pas {{SessionName}} dans votre nom d’utilisateur. Notez que dans {{SessionName}}, le caractère spécial « @ » est remplacé par « - » dans le nom de session. {{SessionNameRaw}} conserve les caractères spéciaux dans le nom de session.

      Type du principal IAM Type Valeur du nom d'utilisateur définie automatiquement par Amazon EKS

      Utilisateur

      STANDARD

      ARN de l'utilisateur IAM. Exemple : arn:aws:iam::<111122223333>:user/<my-user>

      Rôle

      STANDARD

      L’ARN STS du rôle lorsqu’il est assumé. Amazon EKS ajoute {{SessionName}} au rôle.

      Exemple : arn:aws:sts::<111122223333>:assumed-role/<my-role>/{{SessionName}}

      Si l'ARN du rôle que vous avez spécifié contenait un chemin, Amazon EKS le supprime dans le nom d'utilisateur généré.

      Rôle

      EC2_LINUX ou EC2_Windows

      system:node:{{EC2PrivateDNSName}}

      Rôle

      FARGATE_LINUX

      system:node:{{SessionName}}

      Rôle

      HYBRID_LINUX

      system:node:{{SessionName}}

      Vous ne pouvez pas modifier le nom d'utilisateur une fois l'entrée d'accès créée.

  • Si le type de l’entrée d’accès est STANDARD et que vous souhaitez utiliser l’autorisation Kubernetes RBAC, vous pouvez ajouter un ou plusieurs noms de groupes à l’entrée d’accès. Après avoir créé une entrée d'accès, vous pouvez ajouter et supprimer des noms de groupes. Pour permettre au principal IAM d’accéder aux objets Kubernetes de votre cluster, vous devez créer et gérer les ressources d’autorisation Kubernetes basées sur les rôles (RBAC). Créez des objets Kubernetes RoleBinding ou ClusterRoleBinding sur votre cluster qui spécifient le nom du groupe sous forme de subject pour kind: Group. Kubernetes autorise le principal IAM à accéder aux objets du cluster uniquement si ceux-ci sont définis dans un objet Role ou ClusterRole, et si ce rôle est spécifié dans l’objet roleRef de votre liaison. Si vous spécifiez des noms de groupe, il est recommandé de bien maîtriser objets d’autorisation basée sur les rôles (RBAC) . Pour plus d'informations, consultez Utilisation de l'autorisation RBAC dans la documentation Kubernetes.

    Important

    Amazon EKS ne vérifie pas si des objets RBAC Kubernetes existants dans votre cluster incluent les noms de groupes que vous spécifiez. Par exemple, si vous créez une entrée d’accès pour un groupe qui n’existe pas encore, EKS créera ce groupe au lieu de renvoyer une erreur.

    Au lieu ou en complément de l’autorisation Kubernetes pour permettre au principal IAM d’accéder aux objets Kubernetes de votre cluster, vous pouvez associer des stratégies d’accès Amazon EKS à une entrée d’accès. Amazon EKS autorise le principal IAM à accéder aux objets Kubernetes du cluster en fonction des autorisations définies dans la stratégie d’accès. Vous pouvez limiter la portée d’une stratégie d’accès à certains espaces de noms Kubernetes que vous spécifiez. L’utilisation de stratégies d’accès ne nécessite pas de gérer des objets RBAC Kubernetes. Pour de plus amples informations, consultez Association des stratégies d’accès aux entrées d’accès.

  • Si vous créez une entrée d'accès avec le type EC2_LINUX ou EC2_Windows, le principal IAM qui crée l'entrée d'accès doit avoir l'autorisation iam:PassRole. Pour plus d’informations, consultez la section Octroi d’autorisations à un utilisateur pour transférer un rôle à un service AWS dans le IAM Guide de l’utilisateur.

  • À l'instar du comportement IAM standard, la création et les mises à jour des entrées d'accès sont finalement cohérentes et prennent effet au bout de plusieurs secondes après que l'appel API initial a été renvoyé avec succès. Vous devez concevoir vos applications de sorte qu'elles tiennent compte de ces retards potentiels. Nous recommandons de ne pas inclure la création ou la mise à jour d’entrées d’accès dans les parcours applicatifs critiques ou nécessitant une haute disponibilité. Au lieu de cela, procédez aux modifications dans une routine d'initialisation ou d'installation distincte que vous exécutez moins souvent. Veillez également à vérifier que les modifications ont été propagées avant que les processus de production en dépendent.

  • Les entrées d’accès ne prennent pas en charge les rôles liés aux services. Vous ne pouvez pas créer d’entrée d’accès lorsque l’ARN du principal correspond à un rôle lié à un service. Vous pouvez identifier les rôles liés aux services par leur ARN, qui est au format arn:aws:iam::*:role/aws-service-role/*.

Vous pouvez créer une entrée d’accès à l’aide de la AWS Management Console ou de la CLI AWS.

AWS Management Console

  1. Ouvrez la console Amazon EKS.

  2. Choisissez le nom du cluster pour lequel vous souhaitez créer une entrée d'accès.

  3. Choisissez l'onglet Access.

  4. Choisissez Créer une entrée d'accès.

  5. Pour le principal IAM, sélectionnez un utilisateur ou un rôle IAM existant. Les bonnes pratiques IAM recommandent d'accéder à votre cluster en utilisant des rôles IAM dotés d'informations d'identification à court terme, plutôt que des utilisateurs IAM dotés d'informations d'identification à long terme. Pour plus d’informations, consultez Exiger que les utilisateurs humains utilisent la fédération avec un fournisseur d’identité pour accéder à AWS à l’aide d’informations d’identification temporaires dans le Guide d’utilisateur IAM.

  6. Pour Type, si l'entrée d'accès concerne le rôle de nœud utilisé pour les nœuds Amazon EC2 autogérés, sélectionnez EC2 Linux ou EC2 Windows. Dans le cas contraire, acceptez le type par défaut (Standard).

  7. Si le type que vous avez choisi est Standard et que vous souhaitez spécifier un nom d'utilisateur, saisissez-le.

  8. Si le Type que vous avez sélectionné Standard et que vous souhaitez utiliser l’autorisation Kubernetes basée sur RBAC pour le principal IAM, spécifiez un ou plusieurs noms dans le champ Groupes. Si vous ne spécifiez aucun groupe et que vous préférez utiliser l’autorisation Amazon EKS, vous pourrez associer une stratégie d’accès à une étape ultérieure ou après la création de l’entrée d’accès.

  9. (Facultatif) Pour Balises, attribuez des étiquettes à l'entrée d'accès. Par exemple, pour faciliter la recherche de toutes les ressources portant la même balise.

  10. Choisissez Suivant.

  11. Sur la page Ajouter une stratégie d’accès, si le type que vous avez sélectionné était Standard et que vous souhaitez qu’Amazon EKS autorise le principal IAM à accéder aux objets Kubernetes du cluster, suivez les étapes ci-dessous. Sinon, choisissez Next (Suivant).

    1. Pour Nom de la politique, choisissez une stratégie d'accès. Vous ne pouvez pas consulter les autorisations des stratégies d’accès, mais celles-ci incluent des autorisations similaires à celles des objets ClusterRole destinés aux utilisateurs Kubernetes. Pour plus d’informations, consultez la section Rôles destinés aux utilisateurs dans la documentation Kubernetes.

    2. Choisissez l’une des options suivantes :

      • Cluster : sélectionnez cette option si vous souhaitez qu’Amazon EKS autorise le principal IAM à disposer des autorisations définies dans la stratégie d’accès pour l’ensemble des objets Kubernetes du cluster.

      • Espace de noms Kubernetes : sélectionnez cette option si vous souhaitez qu’Amazon EKS autorise le principal IAM à disposer des autorisations définies dans la stratégie d’accès, mais uniquement pour les objets Kubernetes d’un espace de noms spécifique du cluster. Dans le champ Espace de noms, saisissez le nom de l’espace de noms Kubernetes présent sur votre cluster. Si vous souhaitez ajouter des espaces de noms supplémentaires, choisissez Ajouter un nouvel espace de noms et entrez son nom.

    3. Pour ajouter des politiques supplémentaires, Sélectionnez Ajouter une politique. Vous pouvez définir la portée de chaque politique différemment, mais vous ne pouvez ajouter chaque politique qu'une seule fois.

    4. Choisissez Suivant.

  12. Vérifiez la configuration de votre entrée d'accès. Si quelque chose semble incorrect, choisissez Précédent pour revenir en arrière et corriger l'erreur. Si la configuration est correcte, choisissez Créer.

AWS CLI

  1. Installez l’AWS CLI, comme indiqué dans la section Installation du Guide de l’utilisateur de l’interface de la ligne de commande AWS.

  2. Vous pouvez utiliser n’importe lequel des exemples ci-dessous pour créer des entrées d’accès :

    • Créez une entrée d'accès pour un groupe de nœuds Linux Amazon EC2 autogéré. Remplacez my-cluster par le nom de votre cluster, 111122223333 par votre ID de compte AWS, et EKS-my-cluster-self-managed-ng-1 par le nom de votre rôle IAM de nœud. Si votre groupe de nœuds est un groupe de nœuds Windows, remplacez EC2_LINUX par EC2_Windows.

      aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX

      Vous ne pouvez pas utiliser l’option --kubernetes-groups lorsque vous spécifiez un type autre que STANDARD. Vous ne pouvez pas associer de stratégie d’accès à cette entrée d’accès, car son type est une valeur autre que STANDARD.

    • Créez une entrée d’accès permettant à un rôle IAM qui n’est pas utilisé pour un groupe de nœuds autogéré Amazon EC2 d’être autorisé par Kubernetes à accéder à votre cluster. Remplacez my-cluster par le nom de votre cluster, 111122223333 par votre ID de compte AWS, et my-role par le nom de votre rôle IAM. Remplacez Utilisateurs par le nom d’un groupe que vous avez défini dans un objet Kubernetes RoleBinding ou ClusterRoleBinding de votre cluster.

      aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers

    • Créez une entrée d'accès qui permet à un utilisateur IAM de s'authentifier auprès de votre cluster. Cet exemple est fourni car c'est possible, bien que les bonnes pratiques IAM recommandent d'accéder à votre cluster en utilisant des rôles IAM dotés d'informations d'identification à court terme, plutôt que des utilisateurs IAM dotés d'informations d'identification à long terme. Pour plus d’informations, consultez Exiger que les utilisateurs humains utilisent la fédération avec un fournisseur d’identité pour accéder à AWS à l’aide d’informations d’identification temporaires dans le Guide d’utilisateur IAM.

      aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user

      Si vous souhaitez que cet utilisateur ait davantage d’accès au cluster que les autorisations fournies par les rôles de découverte de l’API Kubernetes, vous devez associer une stratégie d’accès à l’entrée d’accès, puisque l’option  --kubernetes-groups n’est pas utilisée. Pour plus d’informations, consultez Association des stratégies d’accès aux entrées d’accès et Rôles de découverte d’API dans la documentation Kubernetes.