web-dev-qa-db-fra.com

Comment utiliser le rôle de tâche AWS ECS dans le noeud AWS SDK

Le code qui utilise le kit AWS Node SDK ne semble pas pouvoir obtenir les autorisations de rôle de la tâche ECS. 

Si j'exécute le code sur une instance EC2 ECS, le code semble hériter du rôle sur l'instance, pas de la tâche. 

Si je lance le code sur Fargate, le code ne reçoit aucune autorisation.

En revanche, tous les scripts bash exécutés dans l'instance semblent disposer des autorisations appropriées.

En effet, la documentation ne mentionne pas cela en tant qu'option pour le noeud sdk, mais simplement:

  1. Chargé à partir de rôles IAM pour Amazon EC2 (s'il est exécuté sur EC2),
  2. Chargé à partir du fichier d'identifiants partagés (~/.aws/credentials),
  3. Chargé à partir de variables d'environnement,
  4. Chargé à partir d'un fichier JSON sur le disque,
  5. Codé en dur dans votre application

Existe-t-il un moyen d'obtenir que votre code de nœud obtienne les autorisations de la tâche ECS?  

Cela semble être le moyen logique de transmettre des autorisations à votre code. Cela fonctionne à merveille avec le code s'exécutant sur une instance.

La seule solution que je puisse envisager consiste à créer un utilisateur IAM par service ECS et à transmettre la clé/le secret de l'API en tant que variables d'environnement dans la définition de la tâche. Cependant, cela ne semble pas très sûr, car il serait visible en texte clair par quiconque ayant accès à la définition de tâche.

amazon-web-servicesamazon-iamamazon-ecsaws-sdk-js
8
Cristian Vrabie

Votre question manque beaucoup de détails sur la configuration de votre cluster ECS et je ne sais pas si la question s'adresse à ECS ou à Fargate en particulier.

Assurez-vous que vous utilisez la dernière version du SDK. Javascript prend en charge les informations d'identification des tâches ECS et Fargate.

Il y a souvent confusion à propos des informations d'identification sur ECS. Il y a le rôle IAM attribué aux instances de cluster EC2 et le rôle IAM attribué aux tâches ECS.

Le problème le plus courant est que la "relation d'approbation" n'a pas été configurée dans le rôle de tâche ECS. Sélectionnez votre rôle IAM, puis l'onglet "Relations de confiance" et assurez-vous qu'il ressemble à ceci:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs-tasks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Outre les autorisations Amazon ECS standard requises pour exécuter des tâches et des services, les utilisateurs IAM doivent également disposer d'autorisations iam:PassRole pour utiliser des rôles IAM pour des tâches.

Vérifiez ensuite que vous utilisez le rôle IAM dans la définition de la tâche. Spécifiez le rôle IAM correct ARN dans le champ Rôle de la tâche. Notez que cela diffère du rôle d'exécution des tâches (qui permet aux conteneurs d'extraire des images et de publier des journaux).

Assurez-vous ensuite que vos instances ECS utilisent la dernière version de l'agent ECS. La version de l'agent est répertoriée dans l'onglet "Instances ECS" sous la colonne de droite "Version de l'agent". La version actuelle est 1.20.3.

Utilisez-vous une AMI optimisée ECS? Sinon, ajoutez --net=Host à votre commande docker run qui lance l'agent. Consultez ce lien link pour plus d’informations.

1
John Hanley

Je l'ai compris. C'était bizarre.

Un collègue a pensé que ce serait "plus sûr" si nous appelions Object.freeze à proccess.env. Cela empêchait en quelque sorte la capacité du SDK d'accéder aux informations d'identification.

Supprimé cette "amélioration" et tout va bien à nouveau. Je pense que la leçon est "ne plaisante pas avec process.env".

0
Cristian Vrabie