Configurer les pods pour utiliser un compte de service Kubernetes - Amazon EKS

Aidez à améliorer cette page

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

Configurer les pods pour utiliser un compte de service Kubernetes

Si un pod doit accéder aux services AWS, vous devez le configurer pour utiliser un compte de service Kubernetes. Le compte de service doit être associé à un rôle Gestion des identités et des accès AWS (IAM) disposant des autorisations nécessaires pour accéder aux services AWS.

  • Un cluster existant. Si vous n’en avez pas, vous pouvez en créer un à l’aide de l’un des guides disponibles dans Mise en route avec Amazon EKS.

  • Un fournisseur IAM OpenID Connect (OIDC) existant pour votre cluster. Pour déterminer si vous en avez déjà un ou comment en créer un, consultez Créer un fournisseur d'identité OIDC IAM pour votre cluster.

  • Un compte de service Kubernetes existant associé à un rôle IAM. Le compte de service doit être annoté avec l'Amazon Resource Name (ARN) du rôle IAM. Le rôle doit être associé à une politique IAM contenant les autorisations dont vos pods veulent avoir pour utiliser les services AWS. Pour plus d'informations sur la façon de créer et de configurer le compte de service et le rôle, consultez Attribution de rôles IAM aux comptes de service Kubernetes.

  • Version 2.12.3 ou ultérieure ou version 1.27.160 ou ultérieure de l’interface de la ligne de commande AWS (AWS CLI) installée et configurée sur votre appareil ou dans AWS CloudShell. Pour vérifier votre version actuelle, utilisez aws --version | cut -d / -f2 | cut -d ' ' -f1. Les gestionnaires de package tels que yum, apt-get ou Homebrew pour macOS ont souvent plusieurs versions de retard par rapport à la dernière version de l’AWS CLI. Pour installer la dernière version, consultez les sections Installation et Configuration rapide avec aws configure du Guide de l’utilisateur de l’interface de la ligne de commande AWS. La version de l’AWS CLI installée dans AWS CloudShell peut également être plusieurs versions derrière la dernière version. Pour la mettre à jour, consultez la section Installation de l’AWS CLI dans votre répertoire personnel dans le Guide de l’utilisateur AWS CloudShell.

  • L’outil de ligne de commande kubectl est installé sur votre appareil ou dans AWS CloudShell. La version peut correspondre à celle utilisée par votre cluster Kubernetes, ou différer d’au plus une version mineure, qu’elle soit antérieure ou plus récente. Par exemple, si la version de votre cluster est 1.29, vous pouvez utiliser la version kubectl 1.28, 1.29 ou 1.30. Pour installer ou mettre à niveau kubectl, veuillez consulter Configuration de kubectl et eksctl.

  • Un fichier existant kubectl config qui contient la configuration de votre cluster. Pour créer un fichier kubectl config, consultez Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig.

    1. Utilisez la commande suivante pour créer un manifeste de déploiement que vous pouvez déployer sur un pod afin de confirmer la configuration. Remplacez les exemples de valeurs par vos propres valeurs.

      cat >my-deployment.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      serviceAccountName: my-service-account
      containers:
      - name: my-app
        image: public.ecr.aws/nginx/nginx:X.XX
EOF

    2. Appliquez le manifeste à votre cluster.

      kubectl apply -f my-deployment.yaml

    3. Vérifiez que les variables d’environnement requises existent pour votre pod.

      1. Affichez les pods qui ont été déployés avec le déploiement à l’étape précédente.

        kubectl get pods | grep my-app

        L'exemple qui suit illustre un résultat.

        my-app-6f4dfff6cb-76cv9   1/1     Running   0          3m28s

      2. Affichez l’ARN du rôle IAM utilisé par le pod.

        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_ROLE_ARN:

        L'exemple qui suit illustre un résultat.

        AWS_ROLE_ARN:                 arn:aws:iam::111122223333:role/my-role

        L'ARN du rôle doit correspondre à l'ARN du rôle avec lequel vous avez annoté le compte de service existant. Pour en savoir plus sur l'annotation du compte de service, consultez Attribution de rôles IAM aux comptes de service Kubernetes.

      3. Vérifiez que le pod dispose d’un fichier de jeton d’identité Web monté.

        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_WEB_IDENTITY_TOKEN_FILE:

        L'exemple qui suit illustre un résultat.

        AWS_WEB_IDENTITY_TOKEN_FILE:  /var/run/secrets/eks.amazonaws.com/serviceaccount/token

        Le kubelet demande et stocke le jeton au nom du pod. Par défaut, kubelet actualise le jeton si ce dernier est supérieur à 80 % de son temps total avant le live, ou si le jeton est âgé de plus de 24 heures. Vous pouvez modifier la durée d’expiration de tout compte autre que le compte de service par défaut à l’aide des paramètres de votre spécification de pod. Pour plus d'informations, consultez la section Projection du volume des jetons de compte de service dans la documentation Kubernetes.

        Le webhook d’identité du pod Amazon EKS sur le cluster surveille les pods qui utilisent un compte de service avec l’annotation suivante :

        eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role

        Le webhook applique les variables d’environnement précédentes à ces pods. Votre cluster n’a pas besoin d’utiliser le webhook pour configurer les variables d’environnement et les montages de fichiers de jeton. Vous pouvez configurer manuellement les pods pour qu’ils disposent de ces variables d’environnement. Les versions prises en charge du kit SDK AWS recherchent d'abord ces variables d'environnement dans le fournisseur de chaîne d'informations d'identification. Les informations d’identification du rôle sont utilisées pour les pods qui répondent à ces critères.

    4. Veuillez vérifier que vos pods peuvent interagir avec les services AWS à l’aide des autorisations que vous avez attribuées dans la politique IAM associée à votre rôle.

      Note

      Lorsqu’un pod utilise les informations d’identification AWS d’un rôle IAM associé à un compte de service, l’interface AWS CLI ou d’autres SDK dans les conteneurs de ce pod utilisent les informations d’identification fournies par ce rôle. Si vous ne restreignez pas l’accès aux informations d’identification fournies au rôle IAM du nœud Amazon EKS, le pod a toujours accès à ces informations d’identification. Pour plus d'informations, consultez Restreindre l'accès au profil d'instance affecté au composant master.

      Si vos pods ne peuvent pas interagir avec les services comme prévu, suivez les étapes suivantes pour vérifier que tout est correctement configuré.

      1. Vérifiez que vos pods utilisent une version du kit SDK AWS qui prend en charge l’assomption d’un rôle IAM via un fichier de jeton d’identité Web OpenID Connect. Pour de plus amples informations, consultez Utiliser IRSA avec le SDK AWS.

      2. Vérifiez que le déploiement utilise le compte de service.

        kubectl describe deployment my-app | grep "Service Account"

        L'exemple qui suit illustre un résultat.

        Service Account:  my-service-account

      3. Si vos pods ne peuvent toujours pas accéder aux services, passez en revue les étapes décrites dans Attribuer des rôles IAM aux comptes de service Kubernetes pour vérifier que votre rôle et votre compte de service sont correctement configurés.