Création d’un rôle pour la fédération OpenID Connect (console) - AWS Identity and Access Management

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éation d’un rôle pour la fédération OpenID Connect (console)

Vous pouvez utiliser des fournisseurs d’identité fédérés OpenID Connect (OIDC) au lieu de créer des utilisateurs AWS Identity and Access Management dans votre Compte AWS. Un fournisseur d'identité vous permet de gérer vos identités utilisateur en dehors d'AWS et de leur accorder les autorisations nécessaires pour accéder aux ressources AWS de votre compte. Pour plus d'informations sur la fédération et les IdP, veuillez consulter Fournisseurs d'identité et fédération.

Prérequis pour la création d’un rôle pour OIDC

Avant de pouvoir créer un rôle pour la fédération OIDC, vous devez tout d’abord suivre les étapes requises suivantes.

Pour préparer la création d’un rôle pour la fédération OIDC
  1. Inscrivez-vous auprès d'un ou plusieurs services offrant une identité OIDC fédérée. Si vous créez une application qui a besoin d'accéder à vos ressources AWS, vous configurez également votre application avec les informations du fournisseur. Ainsi, le fournisseur vous communique un ID d'application ou de public unique pour votre application. (Les fournisseurs utilisent une terminologie différente pour ce processus. Ce guide utilise le terme configurer pour désigner le processus d'identification de votre application auprès du fournisseur.) Vous pouvez configurer plusieurs applications auprès de chaque fournisseur, ou plusieurs fournisseurs avec une seule application. Consultez les informations sur l'utilisation des fournisseurs d'identité comme suit :

  2. Après avoir reçu les informations requises de la part de l'IdP, créez un IdP dans IAM. Pour en savoir plus, consultez Création d’un fournisseur d’identité OpenID Connect (OIDC) dans IAM.

    Important

    Si vous utilisez un fournisseur d'identités OIDC de Google, Facebook ou Amazon Cognito, ne créez pas d'IdP IAM distinct dans l'AWS Management Console. Ces fournisseurs d'identité OIDC sont déjà intégrés à AWS et sont immédiatement disponibles. Ignorez cette étape et créez de nouveaux rôles à l'aide de votre IdP à l'étape suivante.

  3. Préparez les politiques pour le rôle que les utilisateurs authentifiés auprès de l'IdP vont endosser. Comme n'importe quel rôle, celui d'une application mobile inclut deux politiques. L'une est la politique de confiance qui spécifie la personne capable d'endosser le rôle. L'autre est la politique d'autorisation qui spécifie les actions et les ressources AWS auxquelles l'application mobile peut accéder ou non.

    Pour les fournisseurs d'identité Web, nous vous recommandons d'utiliser Amazon Cognito pour gérer les identités. Dans ce cas, utilisez une politique de confiance semblable à cet exemple.

    { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"Federated": "cognito-identity.amazonaws.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east-2:12345678-abcd-abcd-abcd-123456"}, "ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"} } } }

    Remplacez us-east-2:12345678-abcd-abcd-abcd-123456 par l'ID du groupe d'identités qu'Amazon Cognito vous assigne.

    Si vous configurez manuellement un fournisseur d’identité OIDC, lorsque vous créez la politique de confiance, vous devez utiliser trois valeurs pour garantir que seule votre application peut endosser le rôle :

    • Pour l'élément Action, utilisez l'action sts:AssumeRoleWithWebIdentity.

    • Pour l'élément Principal, utilisez la chaîne {"Federated":providerUrl/providerArn}.

      • Pour certains fournisseurs d'identité OpenID Connect (OIDC) courants, providerUrl est une URL. Les exemples suivants incluent des méthodes permettant de spécifier le principal pour certains fournisseurs d'identité courants :

        "Principal":{"Federated":"cognito-identity.amazonaws.com"}

        "Principal":{"Federated":"www.amazon.com"}

        "Principal":{"Federated":"graph.facebook.com"}

        "Principal":{"Federated":"accounts.google.com"}

      • Pour les autres fournisseurs OIDC, utilisez l'Amazon Resource Name (ARN) du fournisseur d'identité OIDC créé dans Étape 2, comme dans l'exemple suivant :

        "Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}

    • Pour l'élément Condition, utilisez une condition StringEquals pour limiter les autorisations. Testez l'ID du groupe d'identités pour Amazon Cognito ou l'ID d'application pour les autres fournisseurs. L'ID du groupe d'identité doit correspondre à l'ID d'application obtenu lors de la configuration de l'application avec le fournisseur d'identité. Cette correspondance entre les ID permet de vérifier que la demande provient bien de votre application.

      Note

      Les rôles IAM pour les groupes d’identités Amazon Cognito font confiance au principal de service cognito-identity.amazonaws.com pour assumer ce rôle. Les rôles de ce type doivent contenir au moins une clé de condition pour limiter les principaux qui peuvent assumer le rôle.

      Des considérations supplémentaires s’appliquent aux groupes d’identités Amazon Cognito qui assument des rôles IAM entre comptes. Les politiques d’approbation associées à ces rôles doivent accepter le principal de service cognito-identity.amazonaws.com et contenir la clé de condition aud permettant de limiter l’attribution de rôles aux utilisateurs issus des groupes d’identités que vous souhaitez. Une politique qui fait confiance aux groupes d’identités Amazon Cognito sans cette condition crée un risque qu’un utilisateur d’un groupe d’identités non prévu puisse assumer le rôle. Pour plus d’informations, consultez la section Politiques d’approbation pour les rôles IAM dans l’authentification de base (classique) dans le Guide du développeur Amazon Cognito.

      Créez un élément de condition semblable à un des exemples suivants, en fonction du fournisseur d'identité que vous utilisez :

      "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}

      "Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}

      "Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}

      "Condition": {"StringEquals": {"accounts.google.com:aud": "66677788899900pro0"}}

      Pour les fournisseurs OIDC, utilisez l'URL complète du fournisseur d'identité OIDC avec la clé de contexte aud, comme dans exemple suivant :

      "Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}

    Note

    Les valeurs du principal dans la politique de confiance pour le rôle sont propres à un fournisseur d'identité. Un rôle pour OIDC ne peut spécifier qu’un seul principal. Par conséquent, si l'application mobile autorise des utilisateurs à se connecter à partir de plusieurs fournisseurs d'identité, créez un rôle distinct pour chaque fournisseur d'identité que vous souhaitez prendre en charge. Créez des politiques de confiance distinctes pour chaque fournisseur d'identité.

    Si un utilisateur utilise une application mobile pour se connecter à partir de Login with Amazon (Connexion avec Amazon, l'exemple suivant de politique de confiance s'appliquerait. Dans l'exemple, amzn1.application-oa2-123456 représente l'ID d'application que Amazon assigne lorsque vous avez configuré l'application à l'aide de Login with Amazon (Connexion avec Amazon).

    { "Version": "2012-10-17", "Statement": [{ "Sid": "RoleForLoginWithAmazon", "Effect": "Allow", "Principal": {"Federated": "www.amazon.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}} }] }

    Si un utilisateur utilise une application mobile pour se connecter à partir de Facebook, l'exemple suivant de politique de confiance s'appliquerait. Dans cet exemple, 111222333444555 représente l'ID d'application que Facebook assigne.

    { "Version": "2012-10-17", "Statement": [{ "Sid": "RoleForFacebook", "Effect": "Allow", "Principal": {"Federated": "graph.facebook.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}} }] }

    Si un utilisateur utilise une application mobile pour se connecter à partir de Google, l'exemple suivant de politique de confiance s'appliquerait. Dans cet exemple, 666777888999000 représente l'ID d'application que Google assigne.

    { "Version": "2012-10-17", "Statement": [{ "Sid": "RoleForGoogle", "Effect": "Allow", "Principal": {"Federated": "accounts.google.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"accounts.google.com:aud": "666777888999000"}} }] }

    Si un utilisateur utilise une application mobile pour se connecter depuis Amazon Cognito, l'exemple de politique de confiance suivant s'applique. Dans cet exemple, us-east:12345678-ffff-ffff-ffff-123456 représente l'ID de groupe d'identités qu'Amazon Cognito assigne.

    { "Version": "2012-10-17", "Statement": [{ "Sid": "RoleForCognito", "Effect": "Allow", "Principal": {"Federated": "cognito-identity.amazonaws.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}} }] }

Création d’un rôle pour OIDC

Après avoir exécuté les prérequis, vous pouvez créer le rôle dans IAM. La procédure suivante décrit comment créer une le rôle pour la fédération OIDC dans la AWS Management Console. Pour créer un rôle à partir de l’interface AWS CLI ou de l'API AWS, consultez les procédures à l'adresse Création d’un rôle pour un fournisseur d’identité tiers (fédération).

Important

Si vous utilisez Amazon Cognito, utilisez la console Amazon Cognito pour configurer les rôles. Sinon, utilisez la console IAM pour créer un rôle pour la fédération OIDC.

Pour créer un rôle IAM pour la fédération OIDC
  1. Connectez-vous à l'outil AWS Management Console, puis ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam/.

  2. Dans le panneau de navigation, choisissez Roles (Rôles), puis Create role (Créer un rôle).

  3. Choisissez l’identité Web comme type d’entité d’approbation et sélectionnez Suivant.

  4. Pour Identity provider (Fournisseur d'identité), choisissez l'IdP de votre rôle :

    • Si vous créez un rôle pour un fournisseur d'identité Web individuel, choisissez entre Login with Amazon (Connexion avec Amazon), Facebook ou Google.

      Note

      Vous devez créer un rôle distinct pour chaque IdP que vous souhaitez prendre en charge.

    • Si vous souhaitez créer un rôle de scénario avancé pour Amazon Cognito, choisissez Amazon Cognito.

      Note

      Vous ne devez créer manuellement un rôle à utiliser avec Amazon Cognito que lorsque vous travaillez sur un scénario avancé. Sinon, Amazon Cognito peut créer des rôles pour vous. Pour plus d'informations sur Amazon Cognito, consultez Fournisseurs d'identité externes - Pools d’identités (identités fédérées) dans le Manuel du développeur Amazon Cognito.

    • Si vous souhaitez créer un rôle pour GitHub Actions, vous devez commencer par ajouter le fournisseur GitHub OIDC à IAM. Après avoir ajouté le fournisseur GitHub OIDC à l'IAM, choisisseztoken.actions.githubusercontent.com.

      Note

      Pour plus d’informations sur la façon de configurer AWS pour faire confiance à au fournisseur OIDC de GitHub en tant qu’identité fédérée, consultez la rubrique GitHub Docs – Configuration d’OpenID Connect dans Amazon Web Services. Pour en savoir plus sur les bonnes pratiques permettant de limiter l'accès aux rôles associés à l'IdP IAM pour GitHub, voir Configuration d'un rôle pour le fournisseur d'identité OIDC GitHub sur cette page.

    • Si vous souhaitez créer un rôle pour HashiCorp Cloud Platform (HCP) Terraform, vous devez commencer par ajouter le fournisseur Terraform OIDC à IAM. Après avoir ajouté le fournisseur Terraform OIDC à IAM, choisissez app.terraform.io.

      Important

      Les rôles IAM pour le fournisseur HashiCorp Cloud Platform (HCP) Terraform OIDC doivent évaluer la clé de condition IAM, app.terraform.io:sub, dans la politique d’approbation des rôles. Cette clé de condition limite les organisations, les projets, les espaces de travail ou les phases d’exécution de HCP Terraform qui peuvent assumer le rôle. Sans cette clé de condition, votre politique d’approbation accorde l’accès à votre rôle et à vos ressources AWS à des identités extérieures à votre organisation, ce qui n’est pas conforme au principe du moindre privilège.

      Si vous définissez ou modifiez une politique d’approbation des rôles pour un rôle associé au fournisseur HCP Terraform OIDC dans votre compte AWS, mais que vous n’évaluez pas la clé de condition IAM app.terraform.io:sub, vous recevrez une erreur. De plus, AWS STS refusera les requêtes d’autorisation si votre politique d’approbation des rôles n’évalue pas cette clé de condition.

  5. Saisissez l'identifiant de votre application. L'étiquette de l'identifiant varie selon le fournisseur que vous choisissez :

    • Si vous souhaitez créer un rôle pour Login with Amazon (Connexion avec Amazon), saisissez l'ID d'application dans le champ Application ID (ID d'application).

    • Si vous souhaitez créer un rôle pour Facebook, saisissez l'ID d'application dans le champ Application ID (ID d'application).

    • Si vous souhaitez créer un rôle pour Google, saisissez le nom du public cible dans le champ Audience (Public cible).

    • Si vous souhaitez créer un rôle pour Amazon Cognito, saisissez l'ID du groupe d'identités que vous avez créé pour vos applications Amazon Cognito dans le champ Identity Pool ID (ID du pool d'identités).

    • Si vous souhaitez créer un rôle pour GitHub Actions, saisissez les informations suivantes :

      • Pour Audience, choisissez sts.amazonaws.com.

      • Pour Organisation GitHub, saisissez le nom de l’organisation GitHub. Le nom de l'organisation GitHub est requis et doit être alphanumérique, tirets compris (-). Vous ne pouvez pas utiliser de caractères génériques (* et ?) dans le nom de l'organisation GitHub.

      • (Facultatif) Pour le Référentiel GitHub, saisissez le nom du référentiel GitHub. Si vous ne précisez pas de valeur, la valeur par défaut devient un caractère de remplacement (*).

      • (Facultatif) Pour la Branche GitHub, saisissez le nom de la branche GitHub. Si vous ne précisez pas de valeur, la valeur par défaut devient un caractère de remplacement (*).

    • Si vous souhaitez créer un rôle pour HashiCorp Cloud Platform (HCP) Terraform, saisissez les informations suivantes :

      • Pour Audience, choisissez aws.workload.identity.

      • Pour Organisation, saisissez le nom de l’organisation. Vous pouvez spécifier un caractère générique (*) pour toutes les organisations.

      • Pour Projet, saisissez le nom du projet. Vous pouvez spécifier un caractère générique (*) pour tous les projets.

      • Pour Espace de travail, saisissez le nom de l’espace de travail. Vous pouvez spécifier un caractère générique (*) pour tous les espaces de travail.

      • Pour Phase d’exécution, saisissez le nom de la phase d’exécution. Vous pouvez spécifier un caractère générique (*) pour toutes les phases d’exécution.

  6. (Facultatif) Pour les Conditions (facultatif), choisissez Ajouter une condition pour créer des conditions supplémentaires à réunir avant que les utilisateurs de votre application ne puissent utiliser les autorisations que le rôle accorde. Par exemple, vous pouvez ajouter une condition qui accorde l'accès aux ressources AWS uniquement à un ID utilisateur IAM spécifique. Vous pouvez par ailleurs ajouter des conditions à la politique de confiance après la création du rôle. Pour en savoir plus, consultez Mise à jour d’une politique d’approbation de rôle .

  7. Vérifiez les informations OIDC que vous avez saisies, puis cliquez sur Suivant.

  8. IAM inclut une liste des politiques gérées par AWS et des politiques gérées par le client dans votre compte. Sélectionnez la politique à utiliser pour la politique d'autorisations ou choisissez Create policy (Créer une politique) pour ouvrir un nouvel onglet de navigateur et créer une nouvelle politique de bout en bout. Pour en savoir plus, consultez Création de politiques IAM. Une fois la politique créée, fermez cet onglet et revenez à l'onglet initial. Cochez la case en regard des politiques d’autorisations que vous souhaitez octroyer aux utilisateurs OIDC. Si vous préférez, vous pouvez ne sélectionner aucune stratégie pour le moment, puis les attacher au rôle ultérieurement. Par défaut, un rôle ne dispose d'aucune autorisation.

  9. (Facultatif) Définissez une limite d'autorisations. Il s'agit d'une fonctionnalité avancée.

    Ouvrez la section Set permissions boundary (Définir une limite d'autorisations) et choisissez Use a permissions boundary to control the maximum role permissions (Utiliser une limite d'autorisations pour contrôler le nombre maximum d'autorisations de rôle). Sélectionnez la politique à utiliser comme limite d'autorisations.

  10. Choisissez Suivant.

  11. Pour Role name (Nom du rôle), saisissez un nom de rôle. Les noms de rôle doivent être uniques dans votre Compte AWS. Ils ne dépendent pas de la casse. Par exemple, vous ne pouvez pas créer deux rôles nommés PRODROLE et prodrole. D'autres ressources AWS pouvant faire référence au rôle, vous ne pouvez pas modifier le nom du rôle après l'avoir créé.

  12. (Facultatif) Pour Description, saisissez une description pour le nouveau rôle.

  13. Pour modifier les cas d'utilisation et les autorisations pour le rôle, choisissez Edit (Modifier) dans les sections Step 1: Select trusted entities (Étape 1 : sélection d'entités de confiance) ou Step 2: Select permissions (Étape 2 : sélection d'autorisations).

  14. (Facultatif) Pour ajouter des métadonnées au rôle, attachez des balises en tant que paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, veuillez consulter Balises pour les ressources AWS Identity and Access Management.

  15. Passez en revue les informations du rôle, puis choisissez Créer un rôle.

Configuration d'un rôle pour le fournisseur d'identité OIDC GitHub

Si vous utilisez GitHub en tant que fournisseur d'identité (IdP) OpenID Connect (OIDC), une bonne pratique consiste à limiter les entités pouvant assumer le rôle associé à l'IdP IAM. Lorsque vous incluez une déclaration de condition dans la politique d'approbation, vous pouvez limiter le rôle à une organisation, un référentiel ou une branche GitHub spécifique. Vous pouvez utiliser la clé de condition token.actions.githubusercontent.com:sub avec des opérateurs de condition de chaîne pour limiter l'accès. Nous vous recommandons de limiter la condition à un ensemble spécifique de référentiels ou de branches au sein de votre organisation GitHub. Pour plus d'informations sur la façon de configurer AWS pour faire confiance à l'OIDC de GitHub en tant qu'identité fédérée, consultez la rubrique GitHub Docs – Configuration d'OpenID Connect dans Amazon Web Services.

Si vous utilisez des environnements GitHub dans des flux de travail d’action ou dans des politiques OIDC, nous vous recommandons vivement d’ajouter des règles de protection à l’environnement pour une sécurité accrue. Utilisez les branches et les balises de déploiement pour limiter les branches et les balises qui peuvent être déployées dans l’environnement. Pour plus d’informations sur la configuration des environnements dotés de règles de protection, consultez la section Branches et balises de déploiement dans l’article Utilisation d’environnements pour le déploiement de GitHub.

Lorsque l'IdP OIDC de GitHub est le principal de confiance pour votre rôle, IAM vérifie la condition de la politique de confiance du rôle pour vérifier que la clé de condition token.actions.githubusercontent.com:sub est présente et que sa valeur n'est pas uniquement un caractère générique (* et ?) ou nulle. IAM effectue cette vérification lors de la création ou de la mise à jour de la politique IAM. Si la clé de condition token.actions.githubusercontent.com:sub est absente ou la valeur clé ne répond pas aux critères de valeur mentionnés, la demande échouera et renverra une erreur.

Important

Si vous ne limitez pas la clé de condition token.actions.githubusercontent.com:sub à une organisation ou à un référentiel spécifique, les actions GitHub des organisations ou des référentiels indépendants de votre volonté peuvent assumer des rôles associés à l'IdP IAM GitHub dans votre compte AWS.

L'exemple de politique d'approbation suivant limite l'accès à l'organisation, au référentiel et à la branche GitHub définis. La valeur de la clé de condition token.actions.githubusercontent.com:sub dans l'exemple suivant est le format de valeur de sujet par défaut documenté par GitHub.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com", "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch" } } } ] }

L'exemple de condition suivant limite l'accès à l'organisation et au référentiel GitHub définis, mais accorde l'accès à n'importe quelle branche du référentiel.

"Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*" } }

L'exemple de condition suivant limite l'accès à tout référentiel ou branche au sein de l'organisation GitHub définie. Nous vous recommandons de limiter la clé de condition token.actions.githubusercontent.com:sub à une valeur spécifique qui limite l'accès aux actions GitHub depuis votre organisation GitHub.

"Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/*" } }

Pour plus d’informations sur les clés de fédération OIDC disponibles pour les contrôles de condition dans les politiques, consultez Clés disponibles pour la AWS OIDC fédération.