Comment puis-je configurer des rôles de tâche IAM dans Amazon ECS afin d'éviter les erreurs « Access Denied » (Accès refusé) ?

Date de la dernière mise à jour : 16/07/2019

Je reçois un message d'erreur « Access Denied » (Accès refusé) lorsque mon application effectue des appels d'API AWS. Comment éliminer cette erreur ?

Brève description

Si vous ne configurez pas correctement des rôles de tâche IAM, vous pouvez recevoir des messages d'erreur « Access Denied » (Accès refusé) lorsque votre application effectue des appels d'API AWS.

Pour éviter cette erreur, fournissez votre rôle de tâche AWS Identity and Access Management (IAM) dans la définition de tâche pour Amazon Elastic Container Service (Amazon ECS). Vos tâches peuvent utiliser ce rôle IAM pour les appels d'API AWS. Le rôle de tâche IAM doit disposer de toutes les autorisations requises par votre application. Si une tâche ne parvient pas à trouver le rôle de tâche IAM en raison de problèmes de configuration, le rôle d'instance Amazon Elastic Compute Cloud (Amazon EC2) est alors utilisé.

Résolution

Pour configurer correctement des rôles IAM pour votre tâche, effectuez les vérifications suivantes :

Confirmer que l'agent de conteneur ECS est en cours d'exécution

Pour confirmer que l'agent de conteneur ECS est en cours d'exécution, exécutez la commande suivante :

docker ps

Activer des rôles IAM dans votre fichier de configuration d'agent de conteneur ECS

1.    Ouvrez votre fichier /etc/ecs/ecs.config.

2.    Pour activer des rôles IAM pour des tâches dans des conteneurs avec des modes réseau bridge et default, définissez ECS_ENABLE_TASK_IAM_ROLE sur true. Reportez-vous à l'exemple suivant :

ECS_ENABLE_TASK_IAM_ROLE=true

3.    Pour activer des rôles IAM pour des tâches dans des conteneurs avec le mode réseau host, définissez ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST sur true. Reportez-vous à l'exemple suivant :

ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true

4.    Pour mettre à jour le fichier de configuration, redémarrez l'agent de conteneur AECS en exécutant l'une des commandes suivantes :

Pour les AMI Amazon Linux optimisées pour Amazon ECS :

sudo stop ecs
sudo start ecs

Pour les AMI Amazon Linux 2 optimisées pour Amazon ECS :

sudo systemctl restart ecs

Confirmer que votre stratégie IAM dispose de la relation d'approbation appropriée avec vos tâches Amazon ECS

Pour confirmer que le rôle IAM dispose de la relation d'approbation appropriée, mettez à jour votre stratégie IAM comme suit :

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

Vérifier les paramètres de proxy pour l'agent de conteneur ECS

Si vous utilisez HTTP_PROXY sur votre configuration d'agent de conteneur Amazon ECS, appliquez le paramètre NO_PROXY comme suit :

NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock

Confirmer que vous utilisez le kit de développement logiciel (SDK) AWS adéquat

L'application qui s'exécute dans votre conteneur doit utiliser une version du kit de développement logiciel (SDK) AWS postérieure à la version de juillet 2016.

Pour mettre à jour votre kit SDK AWS, consultez la section Outils pour créer sur AWS.

Répondre aux exigences pour les AMI non optimisées pour Amazon ECS

Si vous utilisez une AMI non optimisée pour Amazon ECS, définissez les règles obligatoires pour iptables.

Remarque : si vous redémarrez l'instance, les règles pour iptables sont réinitialisées à leur valeur par défaut. Pour éviter une réinitialisation, exécutez l'une des commandes suivantes pour enregistrer les règles :

Pour les AMI Amazon Linux optimisées pour Amazon ECS :

sudo service iptables save

Pour les AMI Amazon Linux 2 optimisées pour Amazon ECS :

sudo iptables-save | sudo tee /etc/sysconfig/iptables && sudo systemctl enable --now iptables

Rendre la variable d'environnement du chemin d'accès aux informations d'identification disponible pour les autres processus que PID 1

La variable d'environnement AWS_CONTAINER_CREDENTIALS_RELATIVE_URI est uniquement disponible pour les processus PID 1 au sein d'un conteneur. Si le conteneur exécute plusieurs processus ou processus init (comme wrapper script, start script ou supervisord), la variable d'environnement n'est pas disponible pour les autres processus que PID 1.

Pour définir votre variable d'environnement afin qu'elle soit disponible pour les autres processus que PID 1, exportez-la dans le fichier .profile. Par exemple, exécutez la commande suivante pour exporter la variable dans le Dockerfile pour votre image de conteneur :

RUN echo 'export $(strings /proc/1/environ | grep AWS_CONTAINER_CREDENTIALS_RELATIVE_URI)' >> /root/.profile

Les processus supplémentaires peuvent à présent accéder à la variable d'environnement.

Remarque : il existe une dépendance sur les chaînes et les commandes grep lorsque vous exportez la variable d'environnement.


Cet article vous a-t-il été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d'aide ?