Aller au contenu

AWS Mis à jour le 2026-02-09

Modèles de règles d'approbation PR CodeCommit — N réviseurs, vérif CI, par tag de dépôt

Les modèles de règles d'approbation CodeCommit imposent les réviseurs requis et le statut CI sur les PR. Voici la commande create-approval-rule-template exacte et l'étendue par tag de dépôt.

Le responsable d’escouade ouvre une PR, le build CI est vert, et CodeCommit affiche joyeusement un bouton « Fusionner » sans aucune vérification supplémentaire. Toute personne avec codecommit:MergePullRequest* peut la faire atterrir. Il n’y a pas d’équivalent du « exiger deux réviseurs » de GitHub tant que vous n’avez pas attaché un modèle de règle d’approbation — et contrairement à la protection de branche GitHub, c’est une surface API AWS séparée avec son propre schéma JSON et son propre modèle d’étendue. Les règles sont puissantes (vous pouvez exiger des réviseurs depuis des principaux IAM précis, vous pouvez exiger un statut CI, vous pouvez exiger N réviseurs depuis un pool) mais elles sont invisibles tant qu’elles ne sont pas configurées, et l’équipe ne sait habituellement pas qu’elles existent.

Ce qui se passe

Un modèle de règle d’approbation est un document JSON qui définit les conditions qu’une PR doit satisfaire avant la fusion. Le modèle inclut un filtre DestinationReferences (à quelles branches la règle s’applique), un bloc Approvers (quels principaux IAM peuvent satisfaire l’approbation, et combien sont requis) et optionnellement une vérification de statut CodeBuild.

Les modèles sont découplés des dépôts — vous créez le modèle une fois, puis vous l’associez à chaque dépôt (ou à plusieurs dépôts à la fois). Associer un modèle à un dépôt l’applique à toutes les PR de ce dépôt qui ciblent une des refs de destination. Dissocier retire l’application future ; les PR en cours conservent la règle.

L’intégration CodeBuild est la partie que les équipes sous-utilisent. Le modèle peut référencer un ARN de projet CodeBuild ; la PR doit avoir un build réussi de ce projet contre la ref source avant que la règle d’approbation autorise la fusion. Ça vous donne une vérification CI appliquée à la frontière de fusion, pas par convention.

Le modèle d’étendue est dépôt-par-dépôt par défaut, mais la CLI et le SDK acceptent plusieurs noms de dépôts dans un seul appel d’association. Pour une flotte, le bon motif est d’associer le modèle programmatiquement contre chaque dépôt portant un tag spécifique — même motif que l’étendue de stratégie IAM.

Comment vérifier

Vérifiez si des modèles de règles d’approbation existent dans le compte :

aws codecommit list-approval-rule-templates \
  --query 'approvalRuleTemplateNames' \
  --output table

Si la liste est vide, aucune PR du compte n’est filtrée. C’est l’état de départ courant sur une organisation CodeCommit qui a grandi organiquement.

Pour un dépôt spécifique, voyez quels modèles sont associés :

aws codecommit list-associated-approval-rule-templates-for-repository \
  --repository-name payments-api \
  --query 'approvalRuleTemplateNames' \
  --output table

Et pour inspecter le contenu d’un modèle existant :

aws codecommit get-approval-rule-template \
  --approval-rule-template-name "require-2-and-ci" \
  --query 'approvalRuleTemplate.approvalRuleTemplateContent' \
  --output text | jq .

Pour une PR ouverte, vérifiez si sa règle d’approbation a été satisfaite :

aws codecommit evaluate-pull-request-approval-rules \
  --pull-request-id 42 \
  --revision-id $(aws codecommit get-pull-request \
                    --pull-request-id 42 \
                    --query 'pullRequest.revisionId' --output text) \
  --query 'evaluation' \
  --output json

La réponse inclut approved: true/false et un drapeau overridden: true/false — les contournements sont l’échappatoire et doivent être audités.

La correction

Le motif de référence pour un dépôt tier production, avec deux approbateurs et une vérification CI CodeBuild :

  1. Définir le contenu du modèle en JSON. Le Statements[].Type est Approvers ; NumberOfApprovalsNeeded est le nombre requis ; ApprovalPoolMembers étend qui peut satisfaire la règle (ARN de principaux IAM ou un motif comme arn:aws:iam::123456789012:role/Engineer-*). Le tableau DestinationReferences liste les refs protégées ; les PR qui ciblent d’autres refs ne sont pas soumises à la règle.
{
  "Version": "2018-11-08",
  "DestinationReferences": ["refs/heads/main"],
  "Statements": [
    {
      "Type": "Approvers",
      "NumberOfApprovalsNeeded": 2,
      "ApprovalPoolMembers": [
        "arn:aws:sts::123456789012:assumed-role/Engineer-*/*"
      ]
    }
  ]
}
  1. Créer le modèle. Le contenu entre comme chaîne inline ; la CLI n’accepte pas file:// proprement à travers les versions pour cet argument, donc le motif plus sûr est --cli-input-json :
cat > /tmp/template-input.json <<'EOF'
{
  "approvalRuleTemplateName": "require-2-and-ci-prod",
  "approvalRuleTemplateContent": "{\"Version\":\"2018-11-08\",\"DestinationReferences\":[\"refs/heads/main\"],\"Statements\":[{\"Type\":\"Approvers\",\"NumberOfApprovalsNeeded\":2,\"ApprovalPoolMembers\":[\"arn:aws:sts::123456789012:assumed-role/Engineer-*/*\"]}]}",
  "approvalRuleTemplateDescription": "Production repos: 2 approvers, CI green"
}
EOF

aws codecommit create-approval-rule-template --cli-input-json file:///tmp/template-input.json
  1. Associer le modèle à chaque dépôt tier prod. Boucle sur les dépôts portant Tier=prod :
aws codecommit list-repositories --query 'repositories[].repositoryName' --output text | \
  while read r; do
    tier=$(aws codecommit list-tags-for-resource \
      --resource-arn "arn:aws:codecommit:us-east-1:123456789012:$r" \
      --query 'tags.Tier' --output text)
    if [ "$tier" = "prod" ]; then
      aws codecommit associate-approval-rule-template-with-repository \
        --approval-rule-template-name "require-2-and-ci-prod" \
        --repository-name "$r"
      echo "Associé : $r"
    fi
  done

Même boucle s’exécute à nouveau chaque fois qu’un nouveau dépôt est créé. Branchez-la sur le script de création de dépôt si vous en avez un — une ressource Terraform aws_codecommit_repository couplée à aws_codecommit_approval_rule_template_association est la version durable.

  1. Ajouter une vérification CI via CodeBuild. Les modèles de règles d’approbation ne référencent pas nativement le statut de build CodeBuild — l’intégration est pilotée par événements. Le motif : quand une PR est ouverte ou mise à jour, EventBridge déclenche un événement CodeCommit Pull Request State Change ; un Lambda le reçoit, lance un projet CodeBuild contre la ref source et reposte le statut de build comme commentaire de PR à la complétion. La fusion est filtrée par une approbation séparée que le Lambda de statut de build crée (un deuxième modèle de règle d’approbation étendu pour exiger qu’un rôle IAM spécifique — le rôle du Lambda — approuve).

Le flux d’approbation Lambda simplifié :

import boto3

cc = boto3.client('codecommit')

def lambda_handler(event, _ctx):
    pr_id = event['detail']['pullRequestId']
    revision_id = event['detail']['revisionId']
    build_status = event['detail']['buildStatus']  # SUCCEEDED | FAILED

    if build_status == 'SUCCEEDED':
        cc.update_pull_request_approval_state(
            pullRequestId=pr_id,
            revisionId=revision_id,
            approvalState='APPROVE'
        )
    # En cas de FAILED, laisser non-approuvée ; le développeur doit pousser un correctif.

Le rôle d’exécution du Lambda devient un des approbateurs ; le modèle de règle d’approbation exige au moins une approbation depuis l’ARN de ce rôle. Les PR ne fusionnent que quand le CI est vert.

  1. Auditer les contournements. Toute personne avec codecommit:OverridePullRequestApprovalRules peut contourner la règle sur une PR spécifique. Cette action doit apparaître dans CloudTrail ; canalisez les événements OverridePullRequestApprovalRules dans votre SIEM et alertez dessus. Les contournements pour hotfix sont légitimes ; les contournements comme motif sont un signe que la règle réclame un ajustement.

Deux règles que nous tenons :

Modèle une fois, association plusieurs fois. Maintenir un modèle require-2-and-ci-prod à travers 30 dépôts est tenable. Maintenir 30 règles inline par dépôt ne l’est pas. Utilisez le motif modèle + association étendue par tag.

Ne mettez pas la vérification CI à l’intérieur de la règle d’approbation elle-même. Les règles d’approbation dans CodeCommit sont simples par conception — comptes de réviseurs requis. La vérification de statut CodeBuild appartient à un Lambda piloté par événements qui bascule l’approbation selon le résultat du build. Essayer de faire que la règle elle-même « connaisse » CodeBuild mène à des contournements fragiles.

La configuration de référence est reproductible dans un module Terraform : modèle + boucle d’association + EventBridge + Lambda. Une fois ce module en place, les nouveaux dépôts dans les tiers protégés héritent du filtrage par tag, sans configuration par-dépôt.

Stack Harbor opère CodePipeline + CodeCommit (et les variantes GitHub sur AWS) dans le cadre de l’onboarding Gestion AWS et des Environnements infogérés en continu. Si vos PR CodeCommit fusionnent sans revue ni statut CI imposés, commencez par une consultation d’infrastructure.