iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Oui : GitHub Actions peut accéder à AWS sans stocker de clés AWS longue durée dans les secrets GitHub. Le workflow demande un jeton OIDC, puis l’échange contre des identifiants temporaires en assumant un rôle IAM. Pour que cette approche soit sûre, limitez précisément les dépôts et contextes autorisés, protégez les déploiements de production et vérifiez le rollback en préproduction plutôt que de vous fier à sa seule configuration.
Comment GitHub Actions s’authentifie auprès d’AWS sans clé stockée
La fédération OIDC remplace les identifiants AWS longue durée enregistrés comme secrets GitHub par une chaîne d’authentification temporaire. Le fournisseur d’identité dans IAM est https://token.actions.githubusercontent.com. Avec l’action officielle aws-actions/configure-aws-credentials, l’audience attendue est sts.amazonaws.com. Le job obtient un jeton OIDC, puis l’action s’en sert pour demander des identifiants temporaires au rôle IAM.
Deux autorisations différentes interviennent. Dans le workflow, id-token: write permet au job de demander son jeton OIDC; cette permission ne lui accorde pas le droit de modifier les ressources AWS. Ce droit dépend des autorisations attachées au rôle IAM assumé. GitHub l’indique dans sa documentation sur OIDC avec AWS.
La fédération évite donc de gérer une clé AWS durable dans les secrets du dépôt, mais ne rend pas automatiquement un workflow sûr. Si le rôle peut modifier des ressources de production, toute identité autorisée à l’assumer peut exercer les permissions que sa politique lui accorde.
#1 Best Overall
Comment limiter les workflows autorisés à assumer le rôle
Configurer la relation de confiance IAM
La politique de confiance du rôle doit vérifier au minimum l’audience et le claim sub du jeton. Ce sujet identifie le contexte GitHub autorisé : par exemple un dépôt et une branche, ou un dépôt et un environnement. Lorsque c’est possible, utilisez une correspondance exacte avec StringEquals et évitez une règle générale comme repo:ORG/REPO:* sans besoin précis.
{
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:ORG/REPO:ref:refs/heads/BRANCH"
}
}
}Ce fragment illustre les conditions de confiance, pas une politique complète prête à appliquer. Remplacez les valeurs d’exemple par celles de votre dépôt et vérifiez le sujet réellement émis. Si le job utilise un environnement GitHub, le sujet prend plutôt une forme telle que repo:ORG/REPO:environment:ENVIRONMENT. Dans ce cas, la restriction de la confiance porte sur l’environnement : ses règles de déploiement doivent donc elles aussi limiter les chemins vers la production.
Vérifier le format du sujet OIDC
Le format du claim sub évolue. D’après la documentation GitHub consultée le 7 octobre 2026, les dépôts créés après le 15 juillet 2026, ainsi que ceux qui activent les claims de sujet immuables, utilisent un sujet contenant des identifiants immuables du propriétaire et du dépôt. Une politique IAM fondée sur l’ancien format peut donc ne pas correspondre au jeton émis. Vérifiez le format du dépôt concerné et ajustez la condition IAM en conséquence; ne supposez pas que tous les dépôts ont le même sujet.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Appliquer le moindre privilège au rôle
La politique d’autorisations IAM attachée au rôle doit limiter les opérations et les ressources nécessaires au déploiement. La condition sub répond à la question « quel contexte GitHub peut assumer ce rôle ? »; les autorisations du rôle répondent à « que peut-il faire dans AWS ? ». Restreindre l’une ne remplace pas l’autre.
Protéger les déploiements de production dans GitHub
- Créez un environnement GitHub de production et configurez les règles disponibles pour votre dépôt, notamment l’approbation requise et les restrictions de branches pertinentes.
- Faites référencer cet environnement par le job de déploiement. Quand les protections de l’environnement s’appliquent, les secrets qui lui sont associés ne deviennent accessibles qu’après leur passage. Si aucune approbation n’est donnée sous 30 jours, le job échoue automatiquement, selon la documentation GitHub sur le contrôle des déploiements.
- Accordez
id-token: writeau job qui en a besoin, puis utilisezaws-actions/configure-aws-credentialspour demander l’accès au rôle. Laissez les permissions AWS dans la politique IAM du rôle, limitées au déploiement requis. - Définissez un groupe
concurrencycohérent pour les déploiements qui ne doivent pas s’exécuter simultanément. Tous les workflows de production concernés doivent choisir le même groupe. GitHub ne lie pas automatiquement les groupes de concurrence aux environnements.
Un environnement, une règle de concurrence et une condition IAM protègent des frontières différentes : l’environnement ajoute des contrôles au processus GitHub, le groupe de concurrence évite des exécutions concurrentes dans le groupe choisi, et IAM limite l’accès à AWS. Les configurer ensemble évite de confondre approbation, séquencement et autorisation.
Quel mécanisme de rollback choisir ?
Le retour arrière dépend du contrôleur de déploiement. « Rollback » ne désigne pas une opération AWS unique : le mécanisme, le point de retour et les éléments à surveiller changent selon que le service utilise ECS rolling update, CodeDeploy ou une mise à jour de stack CloudFormation pilotant ECS blue/green.
| Option | Signal d’échec documenté | Point de retour et opération | À vérifier |
|---|---|---|---|
ECS rolling update avec contrôleur ECS |
Le disjoncteur de déploiement détecte l’échec à atteindre un état stable; des alarmes CloudWatch peuvent également servir de signal. | Avec le rollback activé, ECS revient au dernier déploiement achevé avec succès. Un déploiement antérieur en état COMPLETED est nécessaire. |
État du service et transitions du déploiement; les événements ECS peuvent aussi être suivis via EventBridge. |
| CodeDeploy pour ECS blue/green | Échec du déploiement ou seuil de surveillance configuré. | Le rollback peut redéployer une révision antérieure. Ce redéploiement constitue un nouveau déploiement et reçoit un nouvel identifiant. | Historique CodeDeploy, changement de trafic et état applicatif après le retour. |
| CloudFormation pilotant ECS blue/green | Alarmes et événements de mise à jour de stack selon la configuration. | La procédure documentée consiste à annuler la mise à jour de stack pour arrêter et faire revenir le déploiement. | État et événements CloudFormation ainsi que la santé réelle de l’application. |
Les détails et limites varient selon la configuration. Consultez la documentation AWS sur la détection des échecs de déploiement ECS, le disjoncteur de déploiement ECS, le rollback et le redéploiement CodeDeploy et les déploiements ECS avec CodeDeploy.
Recommended Free Tools
Comment tester réellement un rollback en préproduction
Une option activée ne prouve pas que le retour arrière fonctionnera dans votre système. La documentation décrit les mécanismes, mais elle ne démontre pas le comportement d’une application particulière. Organisez un exercice contrôlé dans un environnement de préproduction adapté à votre architecture.
Best Value
- Préparez un point de retour connu et sain. Pour le rollback automatique ECS, vérifiez qu’un déploiement antérieur est achevé avec l’état
COMPLETED. Pour CodeDeploy, identifiez la révision antérieure à redéployer; pour CloudFormation, connaissez la procédure d’annulation de mise à jour de stack applicable. - Choisissez un échec contrôlé qui correspond au détecteur configuré. Par exemple, faites en sorte qu’un service ne devienne pas stable ou déclenchez l’alarme de santé utilisée pour le déploiement. Évitez un test qui affecterait des utilisateurs ou des données de production.
- Observez le déclenchement du mécanisme attendu. Pour ECS, examinez l’état du déploiement et les événements ECS ou EventBridge, ainsi que les alarmes CloudWatch si elles sont utilisées. Pour CodeDeploy, consultez l’historique du déploiement. Pour CloudFormation, examinez l’état et les événements de la stack.
- Vérifiez le résultat après le retour. Confirmez que l’ancienne version reçoit de nouveau le trafic ou que la stack a retrouvé son état stable, puis contrôlez les signaux de santé de l’application. Un statut de déploiement seul n’établit pas que l’application fonctionne correctement.
- Contrôlez ce que le retour ne défait pas. Examinez les migrations de schéma, les tâches ayant des effets de bord et les ressources externes. Le retour d’une version de code ou d’un ensemble de tâches n’annule pas automatiquement ces effets.
Consignez le signal d’échec, l’action déclenchée, le point de retour obtenu et les contrôles de santé effectués. Ce protocole est une méthode de validation à appliquer à votre système, pas le compte rendu d’un essai déjà réalisé.
Quick Recap
Les erreurs de conception à éviter
- Faire confiance à un sujet trop large : une condition qui autorise indistinctement plusieurs branches ou contextes peut permettre à davantage de workflows d’assumer le rôle que prévu.
- Confondre jeton OIDC et accès AWS :
id-token: writepermet de demander un jeton; ce sont la relation de confiance et les autorisations IAM qui déterminent l’accès aux ressources. - Protéger un environnement sans aligner IAM : si le job utilise un environnement, le sujet OIDC doit correspondre à ce contexte et les règles de l’environnement doivent protéger les déploiements visés.
- Supposer que la concurrence est automatique : un environnement GitHub et un groupe
concurrencyne sont pas liés par défaut; choisissez le même groupe dans les workflows de production concernés. - Activer un rollback sans vérifier son point de retour : le mécanisme ECS cité nécessite un déploiement précédent terminé; un retour vers une version absente ou impropre ne constitue pas une récupération.
- Assimiler retour du code et retour de l’ensemble du système : les modifications de données, scripts et effets externes peuvent persister après le rollback du service.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
