Utilisation d'un rôle IAM pour accorder des autorisations à des applications s'exécutant sur des instances Amazon EC2 - AWS Identity and Access Management
Comment fonctionnent les rôles pour les instances EC2 ?Autorisations requises pour l'utilisation de rôles avec Amazon EC2Comment puis-je commencer ?Informations connexes

Utilisation d'un rôle IAM pour accorder des autorisations à des applications s'exécutant sur des instances Amazon EC2

Les applications qui s'exécutent sur une instance EC2 doivent inclure des informations d'identification AWS dans les demandes d'API AWS. Vos développeurs peuvent stocker directement les informations d'identification AWS dans l'instance EC2 et autoriser les applications de cette instance à les utiliser. Toutefois, dans ce cas, ils doivent gérer les informations d'identification, les transmettre en toute sécurité à chaque instance, puis mettre à jour chaque instance EC2 lorsqu'il convient d'effectuer une rotation des informations d'identification. Ceci représente beaucoup de travail supplémentaire.

Au lieu de cela, il est recommandé d'utiliser un rôle IAM pour gérer les informations d'identification temporaires pour les applications qui s'exécutent sur une instance EC2. Lorsque vous utilisez un rôle, vous n'avez pas à distribuer des informations d'identification à long terme (par exemple, un nom d'utilisateur et un mot de passe ou des clé d'accès) à une instance EC2. À la place, le rôle fournit des autorisations temporaires que les applications peuvent utiliser lors d'appels à d'autres ressources AWS. Lorsque vous lancez une instance EC2, vous spécifiez un rôle IAM à associer à celle-ci. Les applications qui s'exécutent sur l'instance peuvent ensuite utiliser les informations d'identification de sécurité temporaires fournies pour le rôle pour signer les demandes d'API.

L'utilisation de rôles pour l'octroi d'autorisations à des applications qui s'exécutent sur des instances EC2 requiert une configuration supplémentaire. Une application qui s'exécute sur une instance EC2 est extraite d'AWS par le système d'exploitation virtuel. En raison de cette séparation supplémentaire, vous avez besoin d'une autre étape pour affecter un rôle AWS et les autorisations qui lui sont associées à une instance EC2, et également de rendre ces dernières disponibles pour toutes ses applications. Cette étape supplémentaire est la création d'un profil d'instance attaché à l'instance. Le profil d'instance contient le rôle et peut fournir les informations d'identification temporaires du rôle à une application qui s'exécute sur l'instance. Ces informations d'identification temporaires peuvent ensuite être utilisées dans les appels d'API de l'application pour accéder aux ressources et restreindre l'accès aux ressources spécifiées par le rôle uniquement. Notez que vous ne pouvez affecter qu'un seul rôle à une instance EC2 à la fois et que toutes les applications de l'instance partagent le même rôle et les mêmes autorisations.

Une telle utilisation des rôles présente plusieurs avantages. Dans la mesure où les informations d'identification des rôles sont temporaires et font automatiquement l'objet d'une rotation, vous n'avez pas à vous soucier de risques de sécurité à long terme. Par ailleurs, si vous utilisez le même rôle pour plusieurs instances, toute modification apportée au rôle se propage automatiquement à toutes les instances.

Note

Même si un rôle est généralement attribué à une instance EC2 lors du lancement, un rôle peut également être attaché à une instance EC2 en cours d'exécution. Pour savoir comment attacher un rôle à une instance en cours d'exécution, consultez Rôles IAM pour Amazon EC2.

Rubriques

Comment fonctionnent les rôles pour les instances EC2 ?

Dans l'illustration suivante, un développeur exécute une application sur une instance EC2 qui requiert l'accès à un compartiment S3 nommé photos. Un administrateur crée le rôle de service Get-pics et attache le rôle à l'instance EC2. Le rôle inclut une politique d'autorisations qui accorde un accès en lecture seule au compartiment S3 spécifié. Il inclut également une politique d'approbation qui permet à l'instance EC2 d'endosser le rôle et de récupérer les informations d'identification temporaires. Lorsque l'application s'exécute sur l'instance, elle peut accéder au compartiment photos en utilisant les informations d'identification temporaires du rôle. L'administrateur n'a pas besoin d'accorder au développeur l'autorisation d'accéder au compartiment photos et le développeur n'a à aucun moment besoin de partager ou gérer les informations d'identification.

Application d'une instance EC2 qui accède à une ressource AWS

  1. L'administrateur utilise IAM pour créer le rôle Get-pics. Dans la politique d'approbation du rôle, l'administrateur spécifie que seules les instances EC2 peuvent endosser le rôle. Dans la politique d'autorisation du rôle, l'administrateur définit des autorisations en lecture seule pour le compartiment photos.

  2. Un développeur lance une instance EC2 et lui affecte le rôle Get-pics.

    Note

    Si vous utilisez la console IAM, le profil d'instance est géré de manière quasiment transparente pour vous. Toutefois, si vous utilisez l’interface AWS CLI ou l'API pour créer et gérer le rôle et l'instance EC2, vous devez également créer le profil d'instance et lui affecter le rôle, dans une procédure séparée. Ensuite, lorsque vous lancez l'instance, vous devez spécifier le nom du profil d'instance à la place du nom de rôle.

  3. Lorsque l'application est en cours d'exécution, elle obtient des informations d'identification de sécurité temporaires à partir des métadonnées d'instance Amazon EC2, comme décrit dans Extraction des informations d'identification de sécurité à partir des métadonnées d'instance. Il s'agit d'informations d'identification de sécurité temporaires qui représentent le rôle et sont valides pendant une période limitée.

    Dans certains kits SDK AWS, le développeur peut utiliser un fournisseur qui gère de manière transparente les informations d'identification de sécurité temporaires. (La documentation de chaque kit SDK AWS décrit les fonctions prises en charge par le kit SDK pour la gestion des informations d'identification.)

    Sinon, l'application peut obtenir les informations d'identification temporaires directement à partir des métadonnées d'instance de l'instance EC2. Les informations d'identification et les valeurs associées se trouvent dans la catégorie iam/security-credentials/role-name (dans cet exemple, iam/security-credentials/Get-pics) des métadonnées. Si l'application extrait les informations d'identification des métadonnées de l'instance, elle peut les mettre en cache.

  4. À l'aide des informations d'identification temporaires obtenues, l'application peut accéder au compartiment photos. Compte tenu de la politique attachée au rôle Get-pics, l'application dispose d'autorisations en lecture seule.

    Les informations d'identification de sécurité temporaires disponibles sur l'instance font automatiquement l'objet d'une rotation avant leur expiration, afin qu'un ensemble d'informations d'identification valides soit toujours disponible. L'application doit simplement obtenir un nouvel ensemble d'informations d'identification à partir des métadonnées de l'instance avant l'expiration des informations d'identification actuelles. Il est possible d'utiliser le kit SDK AWS pour gérer les informations d'identification afin que l'application n'ait pas besoin d'inclure une logique supplémentaire pour actualiser les informations d'identification. Par exemple, instanciation de clients avec les fournisseurs d'informations d'identification de profil d'instance. En revanche, si l'application extrait les informations d'identification de sécurité temporaires des métadonnées d'instance, puis les met en cache, elle doit obtenir un ensemble d'informations d'identification actualisé toutes les heures, ou au moins 15 minutes avant l'expiration des informations d'identification actuelles. Le délai d'expiration est inclus dans les informations renvoyées dans la catégorie iam/security-credentials/role-name.

Autorisations requises pour l'utilisation de rôles avec Amazon EC2

Pour lancer une instance avec un rôle, le développeur doit avoir l'autorisation de lancer des instances EC2 et de transmettre des rôles IAM.

Dans l'exemple suivant, la politique autorise les utilisateurs à lancer une instance avec un rôle à l'aide d'AWS Management Console. La politique inclut des caractères génériques (*) pour autoriser un utilisateur à transmettre n'importe quel rôle et à réaliser les actions Amazon EC2 énumérées. L'action ListInstanceProfiles permet aux utilisateurs d'afficher tous les rôles disponibles dans le compte AWS.

Exemple de politique qui autorise les utilisateurs à lancer une instance avec n'importe quel rôle à l'aide de la console Amazon EC2

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "IamPassRole",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": "ec2.amazonaws.com"
                }
            }
        },
        {
            "Sid": "ListEc2AndListInstanceProfiles",
            "Effect": "Allow",
            "Action": [
                "iam:ListInstanceProfiles",
                "ec2:Describe*",
                "ec2:Search*",
                "ec2:Get*"
            ],
            "Resource": "*"
        }
    ]
}

Limitation des rôles pouvant être transmis à des instances EC2 (avec PassRole)

Vous pouvez utiliser l'autorisation PassRole pour spécifier les rôles qu'un utilisateur peut transmettre à une instance EC2 lors de son lancement. Cela évite que l'utilisateur exécute des applications ayant davantage d'autorisations qu'il n'en possède, autrement dit qu'il soit en mesure d'obtenir des droits élevés. Par exemple, supposons qu'une utilisatrice nommée Alice soit uniquement autorisée à lancer des instances EC2 et à utiliser des compartiments Amazon S3, mais que le rôle qu'elle transmet à une instance EC2 dispose d'autorisations permettant d'utiliser IAM et Amazon DynamoDB. Dans ce cas, il est possible qu'Alice soit en mesure de lancer l'instance, de s'y connecter, d'obtenir des informations d'identification de sécurité temporaires, puis d'effectuer plus d'actions IAM ou DynamoDB qu'elle n'est autorisée à le faire.

Pour limiter les rôles qu'un utilisateur peut transmettre à une instance EC2, vous pouvez créer une politique qui autorise l'action PassRole. Ensuite, vous attachez la politique à l'utilisateur (ou à un groupe IAM auquel il appartient) qui lancera les instances EC2. Dans l'élément Resource de la politique, vous répertoriez les rôles que l'utilisateur peut transmettre aux instances EC2. Lorsque l'utilisateur lance une instance et lui associe un rôle, Amazon EC2 vérifie si l'utilisateur est autorisé à transmettre ce rôle. Il est entendu que vous devez également vous assurer que le rôle que l'utilisateur est autorisé à transmettre n'inclut pas plus d'autorisations qu'il n'est censé en avoir.

Note

L'action d'API PassRole est différente de RunInstances ou ListInstanceProfiles. Il s'agit en fait d'une autorisation qu'AWS vérifie chaque fois qu'un rôle ARN est passé comme paramètre à une API (ou que la console le fait pour l'utilisateur). Elle permet à un administrateur de contrôler les rôles susceptibles d'être transmis et par quels utilisateurs. Dans le cas présent, elle veille à ce que l'utilisateur soit autorisé à attacher un rôle spécifique à une instance Amazon EC2.

Exemple de politique qui autorise un utilisateur à lancer une instance EC2 avec un rôle spécifique

Dans l'exemple suivant, la politique autorise les utilisateurs à lancer une instance avec un rôle à l'aide de l'API Amazon EC2. L'élément Resource spécifie l'Amazon Resource Name (ARN) d'un rôle. En spécifiant l'ARN, la politique accorde à l'utilisateur l'autorisation de transmettre uniquement le rôle Get-pics. Si l'utilisateur tente de spécifier un autre rôle lors du lancement d'une instance, l'action échoue. L'utilisateur est autorisé à exécuter n'importe quelle instance, qu'il s'agisse de transmettre un rôle ou non.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::account-id:role/Get-pics"
    }
  ]
}

Permettre à un rôle de profil d'instance de passer à un rôle dans un autre compte

Vous pouvez permettre à une application qui s'exécute sur une instance Amazon EC2 d'exécuter des commandes dans un autre compte. Pour ce faire, vous devez autoriser le rôle d'instance EC2 dans le premier compte pour passer à un rôle dans le second compte.

Imaginons que vous utilisez deux comptes AWS et que vous voulez autoriser une application s'exécutant sur une instance Amazon EC2 à exécuter des commandes de la AWS CLI dans les deux comptes. Supposons que l'instance EC2 existe dans le compte 111111111111. Cette instance inclut le rôle de profil d'instance abcd qui permet à l'appli d'effectuer les tâches Amazon S3 my-bucket-1 en lecture seule sur le compartiment dans le même compte 111111111111. Toutefois, l'application doit également être autorisée à endosser le rôle efgh entre comptes pour accéder au compartiment my-bucket-2 Amazon S3 dans le compte 222222222222.

Le rôle de profil d'instance EC2 abcd doit disposer des autorisations suivantes pour autoriser l'application à accéder au compartiment Amazon S3 my-bucket-1 :

Politique d'autorisations de rôle abcd du compte 111111111111

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket-1/*",
                "arn:aws:s3:::my-bucket-1"
            ]
        },
        {
            "Sid": "AllowIPToAssumeCrossAccountRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::222222222222:role/efgh"
        }
    ]
}

Le rôle abcd doit faire confiance au service Amazon EC2 pour endosser le rôle. Pour ce faire, le rôle abcd doit avoir la politique de confiance suivante :

Politique de confiance de rôle abcd du compte 111111111111

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

Supposons que le rôle efgh entre comptes permet aux tâches Amazon S3 en lecture seule sur le compartiment my-bucket-2 dans le même compte 222222222222. Pour ce faire, le rôle efgh entre comptes doit avoir la politique d'autorisations suivante :

Politique d'autorisations de rôle efgh du compte 222222222222

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket-2/*",
                "arn:aws:s3:::my-bucket-2"
            ]
        }
    ]
}

Le rôle efgh doit autoriser le rôle de profil d'instance abcd à l'endosser. Pour ce faire, le rôle efgh doit avoir la politique de confiance suivante :

Politique de confiance de rôle efgh du compte 222222222222

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "efghTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"}
        }
    ]
}

Comment puis-je commencer ?

Pour comprendre le fonctionnement des rôles avec les instances EC2, vous devez utiliser la console IAM pour créer un rôle, lancer une instance EC2 utilisant ce rôle, puis examiner l'instance en cours d'exécution. Vous pouvez examiner les métadonnées de l'instance pour voir comment les informations d'identification temporaires du rôle sont mises à la disposition d'une instance. Il est également possible d'étudier la façon dont une application exécutée sur l'instance peut utiliser un rôle donné. Consultez les ressources suivantes pour en savoir plus.

Pour en savoir plus sur la création de rôles pour des instances EC2, consultez les informations suivantes :