DEV Community: Jean-Christophe Blondet

Déployer sur AWS avec GitHub Actions sans clés d'accès : OIDC, contrôles et un retour arrière vraiment testé

Jean-Christophe Blondet — Fri, 25 Sep 2026 07:40:22 +0000

Dans beaucoup d'équipes, la mise en production tient à une personne. Elle connaît l'ordre des commandes, elle a les bons droits sur la console AWS, et elle sait quoi faire quand ça se passe mal. Le jour où elle est absente, on ne déploie pas, ou on déploie en croisant les doigts.

Un pipeline de mise en production sert à sortir ce savoir de la tête d'une personne pour le mettre dans le dépôt, sous une forme que toute l'équipe peut relire, lancer et, surtout, annuler.

Cet article montre une mise en place réaliste avec GitHub Actions vers AWS (exemple : une application conteneurisée sur ECS), autour de trois idées :

Aucune clé d'accès AWS longue durée stockée dans GitHub : on passe par OIDC.
Des contrôles explicites avant et après le déploiement.
Un retour arrière écrit, et exécuté au moins une fois avant d'en avoir besoin.

Les exemples sont volontairement génériques : adaptez les noms, la région et les commandes à votre projet.

1. Avant le YAML : écrire le périmètre

Un pipeline sans périmètre devient vite une démo. Avant la première ligne, écrivez :

quels dépôts et quelles branches déclenchent un déploiement ;
quel artefact part en production (une image Docker, un bundle statique…) ;
quels environnements AWS (compte, région) sont ciblés ;
quels contrôles sont bloquants (tests, lint, revue, approbation manuelle) ;
ce que « retour arrière » veut dire chez vous (redéployer la version précédente ? restaurer une base ?) et ce qui n'est pas réversible ;
le critère de fin : pour nous, le pipeline est terminé quand un membre de l'équipe l'a relancé lui-même, pas quand la personne qui l'a écrit a réussi un déploiement.

2. Se connecter à AWS sans secret : OIDC

GitHub Actions peut obtenir un jeton OIDC signé pour chaque exécution. AWS l'échange contre des identifiants temporaires d'un rôle IAM. Plus de AWS_SECRET_ACCESS_KEY dans les secrets du dépôt, donc plus de clé à faire tourner ou à voir fuiter.

Côté AWS, une seule fois :

Créer un fournisseur d'identité OIDC IAM pour https://token.actions.githubusercontent.com, audience sts.amazonaws.com.
Créer deux rôles : un pour construire et pousser l'image (branche main), un pour déployer (environnement GitHub production).

Politique de confiance du rôle de déploiement (remplacez 123456789012, mon-org et mon-depot) :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012: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:mon-org/mon-depot:environment:production"
        }
      }
    }
  ]
}

Le point important est la condition sub : seul un job de ce dépôt, qui s'exécute dans l'environnement production, peut assumer ce rôle. Pour le rôle de build, la valeur devient repo:mon-org/mon-depot:ref:refs/heads/main.

Permissions à donner (principe du moindre privilège, à ajuster) :

rôle de build : ecr:GetAuthorizationToken et les actions de push sur le dépôt ECR concerné (ecr:BatchCheckLayerAvailability, ecr:InitiateLayerUpload, ecr:UploadLayerPart, ecr:CompleteLayerUpload, ecr:PutImage) ;
rôle de déploiement : ecs:RegisterTaskDefinition, ecs:UpdateService, ecs:DescribeServices, ecr:DescribeImages (pour le contrôle du retour arrière), et iam:PassRole limité aux rôles de tâche et d'exécution ECS de l'application.

3. Le workflow de déploiement

Fichier .github/workflows/deploy.yml :

name: deploy-production

on:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write   # nécessaire pour obtenir le jeton OIDC

concurrency:
  group: deploy-production
  cancel-in-progress: false   # jamais deux déploiements en parallèle

env:
  AWS_REGION: eu-west-3
  ECR_REPOSITORY: mon-app
  ECS_CLUSTER: mon-cluster
  ECS_SERVICE: mon-service
  CONTAINER_NAME: app

jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make lint
      - run: make test

  build:
    needs: checks
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.AWS_BUILD_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}
      - id: ecr
        uses: aws-actions/amazon-ecr-login@v2
      - name: Build et push de l'image (tag = SHA du commit)
        env:
          REGISTRY: ${{ steps.ecr.outputs.registry }}
        run: |
          docker build -t "$REGISTRY/$ECR_REPOSITORY:$GITHUB_SHA" .
          docker push "$REGISTRY/$ECR_REPOSITORY:$GITHUB_SHA"

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: production   # règles de protection de l'environnement (approbation, etc.)
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.AWS_DEPLOY_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}
      - id: render
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: deploy/task-definition.json
          container-name: ${{ env.CONTAINER_NAME }}
          image: ${{ vars.ECR_REGISTRY }}/${{ env.ECR_REPOSITORY }}:${{ github.sha }}
      - uses: aws-actions/amazon-ecs-deploy-task-definition@v2
        with:
          task-definition: ${{ steps.render.outputs.task-definition }}
          cluster: ${{ env.ECS_CLUSTER }}
          service: ${{ env.ECS_SERVICE }}
          wait-for-service-stability: true
      - name: Smoke test
        run: curl --fail --silent --show-error --retry 5 --retry-delay 10 "${{ vars.HEALTHCHECK_URL }}"

Quelques choix à expliquer à l'équipe :

Le tag d'image est le SHA du commit. On sait exactement ce qui tourne, et revenir en arrière revient à redéployer un SHA connu. Configurez le dépôt ECR en tags immuables pour qu'un tag ne puisse pas être écrasé, et une règle de cycle de vie qui conserve assez d'images pour pouvoir revenir en arrière.
concurrency empêche deux déploiements simultanés sur le même service.
environment: production porte les règles de protection (relecteurs obligatoires, restriction aux branches autorisées). Leur disponibilité dépend de votre offre GitHub et de la visibilité du dépôt : vérifiez la documentation GitHub pour les dépôts privés.
wait-for-service-stability fait échouer le job si le service ECS ne se stabilise pas, au lieu de déclarer victoire trop tôt.
vars.* sont des variables de dépôt ou d'environnement (ARN des rôles, registre ECR, URL de santé) : aucune n'est un secret.

4. Les contrôles : bloquants, lisibles, compris

Un contrôle utile est écrit dans le dépôt, exécuté à chaque fois, et compris par la personne qui relancera le pipeline :

avant : build, lint, tests (et éventuellement scan de dépendances ou d'image) ;
pendant : approbation manuelle via l'environnement si votre équipe la veut ;
après : un smoke test sur un point de santé et, si besoin, quelques vérifications fonctionnelles rapides ;
traçabilité : l'exécution GitHub garde le commit, l'image et l'horodatage de chaque déploiement.

Côté ECS, activez aussi le disjoncteur de déploiement (deploymentCircuitBreaker avec enable: true et rollback: true) : si les nouvelles tâches n'arrivent pas à démarrer, ECS revient automatiquement à la dernière version stable. Ce n'est pas un retour arrière fonctionnel (une version qui démarre mais se comporte mal ne sera pas détectée), c'est un filet de sécurité de plus.

5. Le retour arrière : un workflow à part, testé à froid

Le retour arrière doit être aussi simple à lancer que le déploiement. Fichier .github/workflows/rollback.yml :

name: rollback-production

on:
  workflow_dispatch:
    inputs:
      image_tag:
        description: "SHA complet du commit à redéployer"
        required: true

permissions:
  contents: read
  id-token: write

concurrency:
  group: deploy-production
  cancel-in-progress: false

env:
  AWS_REGION: eu-west-3
  ECR_REPOSITORY: mon-app
  ECS_CLUSTER: mon-cluster
  ECS_SERVICE: mon-service
  CONTAINER_NAME: app

jobs:
  rollback:
    runs-on: ubuntu-latest
    environment: production
    env:
      IMAGE_TAG: ${{ inputs.image_tag }}
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ inputs.image_tag }}   # définition de tâche de la même version que l'image
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.AWS_DEPLOY_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}
      - name: Vérifier que l'image existe
        run: aws ecr describe-images --repository-name "$ECR_REPOSITORY" --image-ids imageTag="$IMAGE_TAG"
      - id: render
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: deploy/task-definition.json
          container-name: ${{ env.CONTAINER_NAME }}
          image: ${{ vars.ECR_REGISTRY }}/${{ env.ECR_REPOSITORY }}:${{ inputs.image_tag }}
      - uses: aws-actions/amazon-ecs-deploy-task-definition@v2
        with:
          task-definition: ${{ steps.render.outputs.task-definition }}
          cluster: ${{ env.ECS_CLUSTER }}
          service: ${{ env.ECS_SERVICE }}
          wait-for-service-stability: true
      - name: Smoke test
        run: curl --fail --silent --show-error --retry 5 --retry-delay 10 "${{ vars.HEALTHCHECK_URL }}"

Trois détails qui évitent les mauvaises surprises :

L'entrée utilisateur passe par une variable d'environnement (IMAGE_TAG) dans les étapes run, jamais interpolée directement dans le script : c'est la protection de base contre l'injection de commandes dans GitHub Actions.
On récupère la définition de tâche de la même version que l'image (ref: du checkout) : variables d'environnement et ressources restent cohérentes avec le code redéployé.
Les migrations de base de données ne se rembobinent pas toutes seules. Si une version a modifié le schéma, le retour arrière applicatif ne suffit pas. Préférez des migrations compatibles dans les deux sens (ajouter d'abord, supprimer plus tard), et écrivez noir sur blanc ce qui n'est pas réversible.

Enfin, exécutez ce workflow une fois, avec l'équipe, un jour calme. Un retour arrière qui n'a jamais tourné n'est qu'une hypothèse.

6. Et avec GitLab CI ou AWS CodePipeline ?

Le choix de l'outil dépend surtout de l'endroit où vit déjà votre code et de qui doit pouvoir approuver :

GitLab CI : même logique OIDC. Le job déclare un jeton avec id_tokens (audience sts.amazonaws.com) puis appelle aws sts assume-role-with-web-identity. Dans la politique de confiance, la condition porte sur la revendication sub au format project_path:mon-groupe/mon-projet:ref_type:branch:ref:main.
AWS CodePipeline : l'orchestration vit dans le compte AWS (souvent avec CodeBuild), ce qui plaît quand la contrainte est « tout dans AWS ». La source GitHub ou GitLab se branche via une connexion, et les pipelines récents proposent des mécanismes de retour arrière au niveau des étapes : vérifiez la documentation de votre version.

Aucun des trois n'est « le meilleur ». Le bon choix est celui que votre équipe saura relire et relancer.

7. Checklist de fin

[ ] Aucun identifiant AWS longue durée dans GitHub : OIDC et rôles dédiés build/déploiement
[ ] Conditions sub restreintes au dépôt, à la branche ou à l'environnement
[ ] Images taguées par SHA, tags immuables, rétention suffisante pour revenir en arrière
[ ] Contrôles bloquants avant le déploiement, smoke test après
[ ] Un seul déploiement à la fois (concurrency)
[ ] Workflow de retour arrière écrit et exécuté une fois
[ ] Documentation dans le dépôt : comment déployer, comment revenir en arrière, qui approuve
[ ] Un membre de l'équipe a relancé le pipeline sans aide

Ce dernier point est le vrai critère de réussite : le pipeline appartient à l'équipe, pas à la personne qui l'a écrit.

Chez CERVOX, c'est exactement ainsi que nous cadrons la mission « Mises en production automatisées » : pipeline dans votre dépôt, contrôles prévus, retour arrière exécuté une fois avec vous, et une fin quand votre équipe relance seule (détails sur nos missions AWS). Des questions sur l'OIDC ou le retour arrière ? Posez-les en commentaire.

Checklist : auditer un compte AWS en lecture seule

Jean-Christophe Blondet — Thu, 24 Sep 2026 22:03:04 +0000

Votre compte AWS « tourne », les factures arrivent, des applications répondent… et pourtant plus personne ne sait vraiment ce qu’il contient. Des ressources créées à la main, des accès hérités, des services oubliés, une architecture qui n’existe que dans la tête d’une personne partie : le risque n’est pas seulement technique, il est opérationnel.

Dans ces situations, le premier réflexe utile n’est souvent pas de « tout remettre au propre » tout de suite. C’est d’observer : inventorier, structurer, documenter, puis décider. C’est exactement l’objet d’un audit de compte AWS en lecture seule — une mission cadrée, avec un livrable que vous gardez, sans modifier l’existant tant que vous n’avez pas validé la suite.

Cette checklist détaille quand ce type d’audit est pertinent, comment le mener, ce que vous recevez, et ce qu’il n’est pas. La fiche mission correspondante est sur CERVOX Services.

Quand un audit lecture seule est le bon premier pas

Un audit en lecture seule est particulièrement utile lorsque l’une de ces situations vous parle :

Compte hérité : rachat, départ d’un prestataire, départ d’un admin, « c’était déjà là ».
Documentation absente ou obsolète : diagrammes datés, runbooks inexistants, secrets et accès dispersés.
Doute sur le coût ou la surface : la facture monte, mais on ne sait pas quelles ressources contribuent vraiment.
Avant une décision structurante : migration, reprise en code (Infrastructure as Code), automatisation des mises en production, due diligence technique.
Incident ou friction récurrente : on corrige au feeling, sans vision globale de l’existant.

En revanche, si vous avez déjà un problème urgent et localisé (service cassé, bascule bloquée, erreur reproductible), une intervention sur un problème AWS — mission distincte — peut être plus adaptée. L’audit reste pertinent ensuite pour éviter de reconstruire la même opacité.

Principe utile : diagnostic avant travaux. On regarde d’abord, on propose ensuite, vous décidez. Rien de sensible n’est modifié sans votre accord.

Ce que « lecture seule » signifie (et ce que ça n’est pas)

Lecture seule signifie que l’analyse s’appuie sur des accès qui consultent l’existant (inventaire, configuration visible, journaux accessibles dans le périmètre) sans appliquer de changements sur les ressources de production dans le cadre de cette mission.

Concrètement :

On ne « nettoie » pas le compte pendant l’audit.
On ne bascule pas d’architecture.
On ne déploie pas de correctifs « au passage ».
On ne revendique pas un label partenaire ou un cadre commercial AWS particulier : l’audit décrit ici est une mission d’analyse cadrée, pas un programme certifié tiers.

Ce que la lecture seule n’empêche pas : formuler des recommandations claires, priorisées, et actionnables — pour que vous (ou une mission ultérieure) choisissiez quoi faire ensuite.

Périmètre écrit avant tout accès

Avant d’ouvrir le moindre accès, le périmètre doit être écrit. C’est non négociable si l’on veut un critère de fin de mission compréhensible.

Le périmètre précise typiquement :

Compte(s) et régions concernés (et ce qui est hors scope).
Objectifs : inventaire, points d’attention, préparation migration, préparation reprise IaC, éclairage coûts, etc.
Profondeur : ce qui sera analysé en détail vs signalé comme « à approfondir ».
Contraintes : fenêtres, interlocuteurs, données sensibles, interdictions explicites.
Livrable attendu et critère de fin : quand l’audit est terminé.

Sans ce cadre, un « audit » devient une exploration sans fin — ou une liste d’opinions. Avec ce cadre, vous savez ce que vous achetez : une analyse bornée, restituée.

Méthodologie (lecture seule uniquement)

La méthode ci-dessous est un cadre de travail, pas une checklist magique toutes situations. Elle reste volontairement générique : les outils AWS évoluent, et chaque compte a son histoire.

1. Accès limités à la mission

Les accès sont limités à ce que la mission demande. Pour un audit, l’intention est la consultation. En fin de mission, les accès sont retirés. Votre compte reste le vôtre.

2. Inventaire des ressources analysées

On dresse un inventaire structuré de ce qui est dans le périmètre : compute, stockage, bases, réseau, identité, orchestration, observabilité, budgets/alertes si présents, etc. L’objectif n’est pas d’énumérer « tout AWS », mais de rendre visible votre réel.

Livrable associé : une vue exploitable (tableaux, regroupements par usage / environnement / criticité — selon ce qui a été convenu).

3. Points d’attention formulés de façon actionnable

Un point d’attention utile dit :

quoi est observé ;
pourquoi cela mérite attention (risque, coût, fragilité opérationnelle, dépendance) ;
quelle suite possible (approfondir, corriger, documenter, accepter le risque).

On évite les formulations vagues du type « à revoir » sans contexte. On évite aussi de transformer l’audit en remédiation improvisée.

4. Analyse structurée

L’analyse organise l’existant : surfaces exposées, dépendances critiques, zones peu documentées, écarts entre « ce qui est censé tourner » et « ce qui tourne ». Selon le périmètre, on peut croiser configuration visible et signaux opérationnels (journaux, alarmes, budgets) lorsqu’ils sont accessibles en lecture.

5. Recommandations = propositions, pas exécution automatique

Les recommandations sont des propositions. Elles ne constituent pas, à elles seules, une mise en conformité marketing, ni une promesse de résultat chiffré inventé. Elles préparent des missions distinctes si vous le souhaitez (intervention, reprise en code, CI/CD, migration, etc.).

6. Restitution et documentation

L’audit se termine quand le périmètre défini a été analysé et que le dossier d’audit vous est remis — avec restitution. La documentation fait partie de la mission, selon le périmètre convenu.

Livrables typiques

Conformément à la description de la mission « Audit de compte AWS » sur cervox.io/services/, vous pouvez recevoir notamment :

un inventaire des ressources analysées ;
les principaux points d’attention ;
une analyse structurée ;
des recommandations ;
la restitution et la documentation.

Terminé quand : le périmètre défini a été analysé et le dossier d’audit vous est remis.

Mots-clés de la fiche mission (rappel) : AWS · lecture seule · inventaire · architecture.

Ce que cet audit n’est PAS

Ce n’est pas…	Pourquoi
Une licence de tout modifier « pour améliorer »	Lecture seule = pas de remédiation glissée dans l’audit
Un abonnement de run / infogérance	Une mission, une fin — pas d’abonnement pour cette offre
Une garantie de baisse de facture chiffrée a priori	Les coûts dépendent de votre usage ; l’audit éclaire, il n’invente pas de %
Un remplacement d’une due diligence M&A complète	La due diligence technique est une mission voisine, au périmètre souvent plus large
Une promesse « on connaît déjà votre compte »	Chaque compte est analysé dans son périmètre écrit

Suites possibles (missions distinctes)

Après restitution, vous choisissez. Exemples de suites (chacune = nouveau périmètre) :

Intervention sur un problème identifié ;
Infrastructure reprise en code (Terraform, AWS CDK, Pulumi…) ;
Mises en production automatisées (pipeline + contrôles + retour arrière si prévu) ;
Migration vers AWS, ou depuis AWS vers un cloud européen, selon votre situation ;
Due diligence technique si le contexte est une opération capitalistique.

Rien n’est enchaîné automatiquement : vous gardez la décision.

FAQ courte

Faut-il donner accès au compte AWS ?

Oui, avec des accès limités à ce que la mission demande. Un audit se fait en lecture seule. Les accès sont retirés à la fin.

Où restent le code et l’infrastructure ?

Chez vous. Les ressources restent dans votre compte ; le livrable d’audit (dossier) vous est remis.

Combien ça coûte ?

Le prix dépend du périmètre. Après un échange de 20 minutes, une estimation écrite peut être fournie sous 24 h ouvrées. Le prix définitif est fixé dans une proposition écrite, avant intervention. Pas d’abonnement.

Intervenez-vous à distance ?

Oui pour l’essentiel des interventions, en France et au Benelux ; sur site lorsque la situation le nécessite.

Travaillez-vous seulement sur AWS ?

Principalement AWS. Azure et Google Cloud peuvent être étudiés selon la mission.

Si votre compte AWS existe mais que sa cartographie réelle vous manque, commencez par le cadrer : décrivez la situation en quelques lignes. Nous indiquons si une mission d’audit lecture seule est pertinente, puis nous écrivons le périmètre avec vous.

→ Décrire votre situation sur CERVOX Services

Contact : contact@cervox.io · +33 4 44 05 07 68