Conditions préalables à la création d'un rôle pour OIDC Création d'un rôle pour l'OIDC Configuration d'un rôle pour le fournisseur d'identité GitHub OIDC

Création d'un rôle pour la fédération OpenID Connect (console)

Vous pouvez utiliser les fournisseurs d'identité fédérés OpenID Connect (OIDC) au lieu de créer AWS Identity and Access Management des utilisateurs dans votre. Compte AWS Avec un fournisseur d'identité (IdP), vous pouvez gérer vos identités d'utilisateurs en dehors de l'extérieur AWS et leur donner les autorisations d'accéder aux AWS ressources de votre compte. Pour plus d'informations sur la fédération et IdPs, voirFournisseurs d'identité et fédération.

Conditions préalables à la création d'un rôle pour OIDC

Avant de créer un rôle pour la fédération OIDC, vous devez d'abord suivre les étapes préalables suivantes.

Pour préparer la création d'un rôle pour la fédération OIDC

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 AWS ressources, vous devez également configurer 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 :
- Login with Amazon Developer Center
- Add Facebook Login to Your App or Website sur le site des développeurs Facebook.
- Using OAuth 2.0 for Login (OpenID Connect) sur le site des développeurs Google.
Après avoir reçu les informations requises de la part de l'IdP, créez un IdP dans IAM. Pour plus d’informations, 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 à votre disposition. Ignorez cette étape et créez de nouveaux rôles à l'aide de votre IdP à l'étape suivante.
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 le Web IdPs, 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 IdP OIDC, lorsque vous créez la politique de confiance, vous devez utiliser trois valeurs garantissant que seule votre application peut assumer 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 OIDC courants IdPs, il providerUrl s'agit d'une URL. Les exemples suivants incluent des méthodes permettant de spécifier le principal pour certaines méthodes courantes IdPs :
    
    "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 pools d'identités Amazon Cognito font confiance au cognito-identity.amazonaws.com principal du service pour assumer ce rôle. Les rôles de ce type doivent contenir au moins une clé de condition afin de limiter le nombre de personnes principales pouvant assumer ce rôle.
  Des considérations supplémentaires s'appliquent aux pools d'identités Amazon Cognito qui assument des rôles IAM entre comptes. Les politiques de confiance associées à ces rôles doivent accepter le principe du cognito-identity.amazonaws.com service et contenir la clé de aud condition permettant de limiter l'attribution de rôles aux utilisateurs issus des pools d'identités que vous souhaitez. Une politique qui fait confiance aux groupes d'identités Amazon Cognito sans cette condition crée le risque qu'un utilisateur d'un pool d'identités involontaire assume ce rôle. Pour plus d'informations, consultez la section Politiques de confiance pour les rôles IAM dans le cadre de l'authentification de base (classique) dans le manuel Amazon Cognito Developer Guide.
  
  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 du pool d'identités attribué par Amazon Cognito.
```
{
      "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 l'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 le rôle pour la fédération OIDC dans le AWS Management Console. Pour créer un rôle à partir de l' AWS API AWS CLI or, consultez les procédures surCré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

Connectez-vous à la console IAM AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/iam/.
Dans le panneau de navigation, choisissez Roles (Rôles), puis Create role (Créer un rôle).
Choisissez le type de rôle OIDC.
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 à IAM, choisissez token.actions.githubusercontent.com.
  
  Note
  Pour plus d'informations sur la façon de AWS configurer GitHub l'OIDC de confiance en tant qu'identité fédérée, consultez GitHub Docs - Configuring OpenID Connect in Amazon Web Services. Pour plus d'informations sur les meilleures pratiques en matière de limitation de l'accès aux rôles associés à l'IdP IAM GitHub pour, Configuration d'un rôle pour le fournisseur d'identité GitHub OIDC consultez cette page.
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, entrez les informations suivantes :
  - Pour Audience, choisissez sts.amazonaws.com.
  - Pour GitHub organisation, entrez le nom de votre GitHub organisation. Le nom de GitHub l'organisation est obligatoire et doit être alphanumérique, y compris les tirets (-). Vous ne pouvez pas utiliser de caractères génériques (* et ?) dans le nom GitHub de l'organisation.
  - (Facultatif) Pour le GitHub référentiel, entrez le nom du GitHub référentiel. Si vous ne précisez pas de valeur, la valeur par défaut devient un caractère de remplacement (*).
  - (Facultatif) Pour GitHub la branche, entrez le nom de la GitHub branche. Si vous ne précisez pas de valeur, la valeur par défaut devient un caractère de remplacement (*).
(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 AWS ressources uniquement pour 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 plus d’informations, consultez Modification d'une politique d'approbation de rôle (console).
Vérifiez vos informations OIDC, puis choisissez Next.
IAM inclut une liste des politiques AWS gérées et 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 plus d’informations, consultez Création de politiques IAM. Une fois la politique créée, fermez cet onglet et revenez à l'onglet initial. Cochez la case à côté des politiques d'autorisation que vous souhaitez imposer aux utilisateurs de l'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.
(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.
Choisissez Suivant.
Pour Role name (Nom du rôle), saisissez un nom de rôle. Les noms de rôles doivent être uniques au sein de 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. Comme d'autres AWS ressources peuvent faire référence au rôle, vous ne pouvez pas modifier le nom du rôle après l'avoir créé.
(Facultatif) Pour Description, saisissez une description pour le nouveau rôle.
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).
(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 Balisage des ressources IAM.
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é GitHub OIDC

Si vous utilisez un GitHub fournisseur d'identité (IdP) OpenID Connect (OIDC), la meilleure pratique consiste à limiter le nombre d'entités pouvant assumer le rôle associé à l'IdP IAM. Lorsque vous incluez une déclaration de condition dans la politique de confiance, vous pouvez limiter le rôle à une GitHub organisation, un référentiel ou une branche 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 cette condition à un ensemble spécifique de référentiels ou de succursales au sein de votre GitHub organisation. Pour plus d'informations sur la façon de AWS configurer GitHub l'OIDC de confiance en tant qu'identité fédérée, consultez GitHub Docs - Configuring OpenID Connect in Amazon Web Services.

Si vous utilisez GitHub des environnements dans des workflows 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 GitHub de déploiement dans l'article Utilisation des environnements pour le déploiement.

Quand GitHub l'IdP OIDC est le principal fiable pour votre rôle, IAM vérifie la condition de la politique de confiance des rôles pour vérifier que la token.actions.githubusercontent.com:sub clé de condition est présente et que sa valeur n'est pas uniquement un caractère générique (* et ?) ou nul. 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, GitHub les actions provenant d'organisations ou de référentiels indépendants de votre volonté peuvent assumer les rôles associés à l' GitHub IdP IAM dans votre compte. AWS

L'exemple de politique de confiance suivant limite l'accès à l' GitHub organisation, au référentiel et à la succursale définis. La token.actions.githubusercontent.com:sub valeur de la clé de condition dans l'exemple suivant est le format de valeur d'objet 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' GitHub organisation et au référentiel 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 à n'importe quel référentiel ou branche au sein de l' GitHub organisation 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 GitHub actions au sein de votre GitHub organisation.


"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 vérifications d'état dans les politiques, consultezClés disponibles pour la AWS fédération OIDC.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Création d'un rôle pour la fédération d'identité

Création d'un rôle pour la fédération SAML 2.0

Création d'un rôle pour la fédération OpenID Connect (console)

Conditions préalables à la création d'un rôle pour OIDC

Pour préparer la création d'un rôle pour la fédération OIDC

Important

Note

Note

Création d'un rôle pour l'OIDC

Important

Pour créer un rôle IAM pour la fédération OIDC

Note

Note

Note

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

Important