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 les fournisseurs d'identité fédérés OpenID Connect (OIDC) au lieu de créer des AWS Identity and Access Management 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 OIDC la fédération, vous devez d'abord suivre les étapes préalables suivantes.
Pour préparer la création d'un rôle pour la OIDC fédération
-
Inscrivez-vous à un ou plusieurs services proposant une OIDC identité 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 :
-
Add Facebook Login to Your App or Website
sur le site des développeurs Facebook. -
Utilisation de la OAuth version 2.0 pour la connexion (OpenID Connect)
sur le site des développeurs de Google.
-
Après avoir reçu les informations requises de la part de l'IdP, créez un IdP dans. IAM Pour de plus amples informations, veuillez consulter Créez un fournisseur d'identité OpenID Connect (OIDC) dans IAM.
Important
Si vous utilisez un OIDC IdP de Google, Facebook ou Amazon Cognito, ne créez pas d'IAMIdP distinct dans le. AWS Management Console Ces fournisseurs OIDC d'identité 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 OIDC IdP, 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'actionsts:AssumeRoleWithWebIdentity
. -
Pour l'élément
Principal
, utilisez la chaîne{"Federated":
.providerUrl/providerArn
}-
Pour certains courants OIDC IdPs, il s'
agit d'unURL. Les exemples suivants incluent des méthodes permettant de spécifier le principal pour certaines méthodes courantes IdPs :providerUrl
"Principal":{"Federated":"cognito-identity.amazonaws.com"}
"Principal":{"Federated":"www.amazon.com"}
"Principal":{"Federated":"graph.facebook.com"}
"Principal":{"Federated":"accounts.google.com"}
-
Pour les autres OIDC fournisseurs, utilisez le nom de ressource Amazon (ARN) de l'OIDCIdP que vous avez 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 conditionStringEquals
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 IDs garantit que la demande provient de votre application.Note
IAMles rôles pour les pools d'identités Amazon Cognito font confiance au principal du service
cognito-identity.amazonaws.com
pour assumer le 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 groupes d'identités Amazon Cognito qui assument des rôles entre IAM comptes. Les politiques de confiance associées à ces rôles doivent accepter le principe du
cognito-identity.amazonaws.com
service et contenir la clé deaud
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 les politiques de confiance relatives aux IAM rôles 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 OIDC fournisseurs, utilisez le terme complet URL de l'OIDCIdP avec la clé de
aud
contexte, comme dans l'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 ne OIDC 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 attribué par Amazon lorsque vous avez configuré l'application à l'aide de Login with 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'identifiant de l'application attribué par Facebook.{ "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 attribué par Google.{ "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 OIDC
Une fois les prérequis remplis, vous pouvez créer le rôle dansIAM. La procédure suivante décrit comment créer le rôle de OIDC fédération dans le AWS Management Console. Pour créer un rôle à partir du AWS CLI ou AWS API, consultez les procédures à l'adresseCré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 IAM console pour créer un rôle pour la OIDC fédération.
Pour créer un IAM rôle pour la OIDC fédération
Connectez-vous à la IAM console 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 l'identité Web comme type d'entité de confiance et sélectionnez Suivant.
-
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 GitHub OIDC fournisseur àIAM. Après avoir ajouté le GitHub OIDC fournisseur àIAM, choisissez token.actions.githubusercontent.com.
Note
Pour plus d'informations sur la configuration AWS d'OpenID Connect GitHub OIDC 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'IAMIdP pour GitHub, consultez cette Configuration d'un rôle pour le fournisseur GitHub OIDC d'identité 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 IAM utilisateur spécifique. Vous pouvez par ailleurs ajouter des conditions à la politique de confiance après la création du rôle. Pour de plus amples informations, veuillez consulter Mettre à jour une politique de confiance dans les rôles .
-
Vérifiez vos OIDC informations, puis choisissez Next.
-
IAMinclut 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 de plus amples informations, veuillez consulter 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 OIDC imposer aux utilisateurs. 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
etprodrole
. Dans la mesure AWS où d'autres ressources peuvent faire référence au rôle, vous ne pouvez pas modifier le nom du rôle une fois que vous l'avez 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 de balises dansIAM, consultezBalisage 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 GitHub OIDC d'identité
Si vous l'utilisez GitHub en tant que fournisseur d'identité (IdPOIDC) OpenID Connect (), 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 configuration AWS d'OpenID Connect GitHub OIDC en tant qu'identité fédérée, consultez GitHub Docs - Configuring OpenID Connect in Amazon
Si vous utilisez GitHub des environnements dans des workflows d'action ou dans des OIDC politiques, 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
Quand GitHub l'OIDCIdP est le principal de confiance pour votre rôle, IAM vérifie la condition de la politique de confiance des rôles 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 nul. IAMeffectue cette vérification lors de la création ou de la mise à jour de la politique de confiance. 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 IAMIdP dans AWS votre compte.
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 OIDC de fédération disponibles pour les vérifications d'état dans les politiques, consultezClés disponibles pour la AWS OIDC fédération.