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.
Migration de la version préliminaire publique à la disponibilité générale
Si vous avez utilisé AWS DevOps l'Agent lors de la version préliminaire publique, vous devez mettre à jour vos rôles IAM avant la sortie de GA. Ce guide explique comment mettre à jour les rôles de surveillance et les rôles d'opérateur dans vos comptes.
Ce qui change
Historique des discussions à la demande depuis l'aperçu public
La version GA introduit des mesures de sécurité supplémentaires pour renforcer les contrôles d'accès aux historiques de discussion. En raison de ces modifications, les historiques des discussions à la demande datant de la période de prévisualisation publique (avant le 30 mars 2026) ne sont plus accessibles. Les journaux d'investigation et les résultats créés lors de l'avant-première publique ne sont pas affectés. Cette modification s'applique uniquement aux conversations par chat à la demande.
Nouvelles politiques gérées
Pour GA, AWS fournit de nouvelles politiques gérées qui remplacent les politiques de l'ère de prévisualisation :
| Type de rôle | Supprimer | Addition |
|---|---|---|
| Contrôle | Stratégie gérée par AIOpsAssistantPolicy |
Stratégie gérée par AIDevOpsAgentAccessPolicy |
| Opérateur (IAM et IDC) | Politique en ligne | Stratégie gérée par AIDevOpsOperatorAppAccessPolicy |
En outre, les rôles d'opérateur nécessitent des politiques de confiance mises à jour, et les rôles d'opérateur IDC nécessitent une nouvelle politique intégrée.
Conditions préalables
Accès aux AWS comptes sur lesquels vos rôles d' DevOps agent sont configurés (comptes principaux et tous les comptes secondaires)
Autorisations IAM pour modifier les rôles, les politiques et les relations de confiance
Votre identifiant d'espace agent, votre identifiant de AWS compte et votre région (visibles dans la console DevOps Agent)
Étape 1 : Mettre à jour les rôles de surveillance
Mettez à jour le rôle de surveillance dans votre compte principal et dans chaque compte secondaire. Il s'agit des rôles Primary/Secondary source configurés sous l'onglet Capabilities de votre espace agent (exemple de primary/secondary rôle :DevOpsAgentRole-AgentSpace-3xj2396z).
Dans la console de l' DevOps agent, accédez à votre espace agent et choisissez l'onglet Fonctionnalités.
Trouvez le rôle de surveillance de vos Primary/Secondary sources (par exemple,
DevOpsAgentRole-AgentSpace-3xj2396z) et choisissez Modifier.Sous Politiques d'autorisations, supprimez la politique
AIOpsAssistantPolicyAWS gérée.Choisissez Ajouter des autorisations, Joindre des politiques, puis attachez la politique
AIDevOpsAgentAccessPolicygérée.Modifiez la politique en ligne et remplacez son contenu par ce qui suit, en remplaçant votre identifiant de compte :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCreateServiceLinkedRoles", "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole" ], "Resource": [ "arn:aws:iam::<account-id>:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer" ] } ] }
La politique de confiance relative au rôle de surveillance ne nécessite aucune modification. Vérifiez qu'il correspond aux critères suivants :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "aidevops.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "<account-id>" }, "ArnLike": { "aws:SourceArn": "arn:aws:aidevops:<region>:<account-id>:agentspace/*" } } } ] }
Répétez les étapes 2 à 6 pour le rôle de surveillance dans chaque compte secondaire.
Étape 2 : Mettre à jour le rôle d'opérateur (IAM)
Dans la console de l' DevOps agent, choisissez l'onglet Accès et recherchez le rôle de l'opérateur.
Dans la console IAM, supprimez la politique intégrée existante du rôle d'opérateur.
Choisissez Ajouter des autorisations, Joindre des politiques, puis attachez la politique
AIDevOpsOperatorAppAccessPolicygérée.Choisissez l'onglet Relations de confiance, puis sélectionnez Modifier la politique de confiance. Remplacez la politique de confiance par la suivante, en remplaçant votre identifiant de compte, votre région et votre identifiant Agent Space :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "aidevops.amazonaws.com" }, "Action": ["sts:AssumeRole", "sts:TagSession"], "Condition": { "StringEquals": { "aws:SourceAccount": "<account-id>" }, "ArnEquals": { "aws:SourceArn": "arn:aws:aidevops:<region>:<account-id>:agentspace/<agentspace-id>" } } } ] }
Étape 3 : Mettre à jour les rôles des opérateurs (IDC)
Si vous utilisez IAM Identity Center avec un DevOps agent, mettez à jour chaque rôle d'opérateur IDC.
Dans la console IAM, accédez à Rôles et recherchez
WebappIDCvos rôles IDC d' DevOps agent (par exemple,DevOpsAgentRole-WebappIDC-<id>).Pour chaque rôle IDC :
a. Supprimez la politique intégrée existante.
b. Choisissez Ajouter des autorisations, Joindre des politiques, puis attachez la politique AIDevOpsOperatorAppAccessPolicy gérée.
c. Choisissez l'onglet Relations de confiance, puis sélectionnez Modifier la politique de confiance. Remplacez la politique de confiance par la suivante, en remplaçant votre identifiant de compte, votre région et votre identifiant Agent Space :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "aidevops.amazonaws.com" }, "Action": ["sts:AssumeRole", "sts:TagSession"], "Condition": { "StringEquals": { "aws:SourceAccount": "<account-id>" }, "ArnEquals": { "aws:SourceArn": "arn:aws:aidevops:<region>:<account-id>:agentspace/<agentspace-id>" } } }, { "Sid": "TrustedIdentityPropagation", "Effect": "Allow", "Principal": { "Service": "aidevops.amazonaws.com" }, "Action": "sts:SetContext", "Condition": { "StringEquals": { "aws:SourceAccount": "<account-id>" }, "ArnEquals": { "aws:SourceArn": "arn:aws:aidevops:<region>:<account-id>:agentspace/<agentspace-id>" }, "ForAllValues:ArnEquals": { "sts:RequestContextProviders": [ "arn:aws:iam::aws:contextProvider/IdentityCenter" ] }, "Null": { "sts:RequestContextProviders": "false" } } } ] }
d. Créez une nouvelle politique en ligne avec les autorisations suivantes, en remplaçant votre identifiant de compte :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowDevOpsAgentSSOAccess", "Effect": "Allow", "Action": [ "sso:ListInstances", "sso:DescribeInstance" ], "Resource": "*" }, { "Sid": "AllowDevOpsAgentIDCUserAccess", "Effect": "Allow", "Action": "identitystore:DescribeUser", "Resource": [ "arn:aws:identitystore::<account-id>:identitystore/*", "arn:aws:identitystore:::user/*" ] } ] }
Reconnectez le centre d'identité IAM (le cas échéant)
Les espaces d'agent créés lors de la préversion publique peuvent comporter une application IAM Identity Center configurée avec une étendue d'accès obsolète. Pour GA, le champ d'application correct est aidevops:read_write. Si votre application IAM Identity Center possède l'étendue précédente (awsaidevops:read_write), vous devez déconnecter puis reconnecter IAM Identity Center.
Comment vérifier le périmètre de votre application IAM Identity Center
Exécutez la commande AWS CLI suivante pour vérifier le périmètre de votre application IAM Identity Center. Vous trouverez l'ARN de l'application dans la console IAM Identity Center sous Applications.
aws sso-admin list-application-access-scopes \ --application-arn arn:aws:sso::<account-id>:application/<instance-id>/<application-id>
La sortie doit afficher la portée correcte aidevops:read_write:
{ "Scopes": [ { "Scope": "aidevops:read_write" } ] }
Si le scope l'indique awsaidevops:read_write, il est obsolète. Suivez les étapes ci-dessous pour le mettre à jour.
Comment reconnecter IAM Identity Center
L'étendue d'accès d'une application IAM Identity Center AWS gérée ne peut pas être mise à jour directement. Vous devez vous déconnecter puis vous reconnecter :
Dans la console de l' AWS DevOps agent, accédez à votre espace agent et choisissez l'onglet Accès.
Choisissez Déconnecter à côté de la configuration du centre d'identité IAM.
Confirmez la déconnexion.
Choisissez Connect pour configurer à nouveau IAM Identity Center. Le service crée une nouvelle application IAM Identity Center avec le périmètre approprié.
Réaffectez les utilisateurs et les groupes à la nouvelle application dans la console IAM Identity Center.
Important
La déconnexion supprime le chat individuel des utilisateurs et l'historique des artefacts associés aux comptes utilisateurs d'IAM Identity Center. Les utilisateurs devront se reconnecter après leur reconnexion.
Vérification
Après avoir effectué toutes les étapes :
Retournez à la console de l' DevOps agent et vérifiez qu'aucune erreur d'autorisation n'apparaît dans l'onglet Agent Space Access.
Testez l'application Web de l'opérateur pour vérifier qu'elle se charge et fonctionne correctement.
Si vous utilisez IDC, vérifiez que les utilisateurs peuvent s'authentifier et accéder à l'expérience de l'opérateur.
Résolution des problèmes
Erreurs d'autorisation refusée après la migration
Vérifiez qu'il
AIOpsAssistantPolicya été supprimé et qu'AIDevOpsAgentAccessPolicyil est associé aux rôles de surveillance.Vérifiez que les anciennes politiques intégrées ont été supprimées et qu'elles
AIDevOpsOperatorAppAccessPolicysont associées aux rôles des opérateurs.Vérifiez que les politiques de confiance des opérateurs incluent
sts:TagSession.Vérifiez que vous avez remplacé toutes les valeurs d'espace réservé (
<account-id>,<region>,<agentspace-id>) par des valeurs réelles.
Les comptes secondaires ne fonctionnent pas
Le rôle de surveillance de chaque compte secondaire doit être mis à jour indépendamment. Connectez-vous à chaque compte et répétez l'étape 1.
Défaillances d'authentification IDC
Vérifiez que la politique de confiance d'IDC inclut à la fois l'
sts:TagSessioninstructionsts:AssumeRole/et laTrustedIdentityPropagationdéclaration.Confirmez la politique en ligne avec
sso:ListInstancessso:DescribeInstance, etidentitystore:DescribeUsera été créée.
L'historique des discussions à la demande est manquant après la migration
L'historique des discussions à la demande datant de la période de préversion publique ne sera plus accessible après la sortie de GA. Ce comportement est attendu en raison des mesures de sécurité renforcées introduites en Géorgie. Les journaux d'investigation et les résultats publiés en avant-première ne sont pas affectés.