Si vos workflows GitHub Actions s’authentifient aupr\u00e8s d’AWS en utilisant La f\u00e9d\u00e9ration OpenID Connect (OIDC) \u00e9limine enti\u00e8rement ce risque. Au lieu de stocker des credentials AWS statiques dans GitHub, votre workflow demande un jeton OIDC \u00e0 courte dur\u00e9e de vie aupr\u00e8s du fournisseur d’identit\u00e9 de GitHub. AWS valide ce jeton, v\u00e9rifie les claims (d\u00e9p\u00f4t, branche, environnement), et \u00e9met des credentials temporaires qui expirent en quelques minutes. Aucun secret n’est stock\u00e9 nulle part \u2014 la relation de confiance est \u00e9tablie entre le fournisseur OIDC de GitHub et votre r\u00f4le IAM AWS.<\/p>\n Dans ce lab pratique, vous allez :<\/p>\n \u00c0 la fin de ce lab, votre pipeline CI\/CD n’aura aucun credential AWS stock\u00e9, et chaque \u00e9v\u00e9nement d’authentification sera tra\u00e7able jusqu’\u00e0 un d\u00e9p\u00f4t, une branche, un commit et une ex\u00e9cution de workflow sp\u00e9cifiques.<\/p>\n Avant de commencer ce lab, assurez-vous de disposer des \u00e9l\u00e9ments suivants :<\/p>\n Dur\u00e9e estim\u00e9e : 60 \u00e0 90 minutes<\/strong><\/p>\n Avant d’impl\u00e9menter OIDC, \u00e9tablissons le mod\u00e8le non s\u00e9curis\u00e9 que vous allez remplacer. Cela rend l’am\u00e9lioration de la s\u00e9curit\u00e9 concr\u00e8te et vous donne un workflow fonctionnel \u00e0 migrer.<\/p>\n Cr\u00e9ez un nouveau d\u00e9p\u00f4t GitHub appel\u00e9 Si vous avez un utilisateur IAM existant avec un acc\u00e8s programmatique, stockez ses credentials comme secrets GitHub :<\/p>\n Pourquoi c’est dangereux :<\/strong><\/p>\n Cr\u00e9ez Committez et poussez ce workflow. Confirmez qu’il s’ex\u00e9cute avec succ\u00e8s \u2014 c’est la base que vous allez remplacer par OIDC.<\/p>\n La premi\u00e8re \u00e9tape de la f\u00e9d\u00e9ration OIDC consiste \u00e0 indiquer \u00e0 AWS de faire confiance au fournisseur d’identit\u00e9 de GitHub. C’est une configuration unique par compte AWS.<\/p>\n Note :<\/strong> AWS v\u00e9rifie d\u00e9sormais automatiquement l’empreinte du fournisseur OIDC de GitHub. La valeur de l’empreinte dans la ressource Terraform est requise par l’API mais AWS validera la cha\u00eene de certificats quelle que soit la valeur fournie.<\/p>\n Confirmez que le fournisseur a \u00e9t\u00e9 cr\u00e9\u00e9 :<\/p>\n Vous devriez voir un ARN comme :<\/p>\n Cr\u00e9ez maintenant un r\u00f4le IAM que GitHub Actions peut assumer via OIDC. La politique de confiance est la partie la plus critique \u2014 elle d\u00e9termine exactement quels d\u00e9p\u00f4ts, branches et environnements peuvent assumer ce r\u00f4le.<\/p>\n Enregistrez ce qui suit dans Suivez le principe du moindre privil\u00e8ge. Pour ce lab, attachez une politique qui accorde un acc\u00e8s en lecture seule \u00e0 un bucket S3 sp\u00e9cifique :<\/p>\n Remplacez maintenant le workflow avec credentials statiques par l’authentification OIDC. C’est l’\u00e9tape principale de la migration.<\/p>\n Remplacez le contenu de Naviguez vers l’onglet Actions<\/strong> dans votre d\u00e9p\u00f4t GitHub. Vous devriez voir le workflow en cours d’ex\u00e9cution. Dans l’\u00e9tape \u00ab Verify Identity \u00bb, la sortie ressemblera \u00e0 :<\/p>\n Remarquez que l’ARN montre Le claim C’est la configuration de l’exercice 2. Seuls les workflows d\u00e9clench\u00e9s par un push vers Les environnements GitHub fournissent une couche suppl\u00e9mentaire de contr\u00f4le d’acc\u00e8s. Lorsqu’un job sp\u00e9cifie un Autoriser uniquement les releases tagg\u00e9es (par exemple, Cr\u00e9ez une branche de fonctionnalit\u00e9 et poussez une ex\u00e9cution de workflow :<\/p>\n Si votre politique de confiance restreint \u00e0 Maintenant, poussez le m\u00eame changement vers Le workflow sur Les d\u00e9ploiements en production doivent avoir des contr\u00f4les plus stricts que le staging. Dans cet exercice, vous cr\u00e9ez des r\u00f4les IAM s\u00e9par\u00e9s pour chaque environnement, avec des politiques de confiance et des permissions diff\u00e9rentes.<\/p>\n Dans votre d\u00e9p\u00f4t, allez dans Param\u00e8tres<\/strong> \u2192 Environnements<\/strong> :<\/p>\n Le r\u00f4le de staging fait confiance \u00e0 toutes les branches du d\u00e9p\u00f4t :<\/p>\n Le r\u00f4le de production fait confiance uniquement \u00e0 l’environnement Cr\u00e9ez un workflow qui d\u00e9ploie automatiquement en staging et en production avec approbation manuelle :<\/p>\n Lorsque ce workflow s’ex\u00e9cute :<\/p>\n La politique de confiance du r\u00f4le de production utilise L’authentification OIDC cr\u00e9e des pistes d’audit d\u00e9taill\u00e9es dans AWS CloudTrail. Chaque appel Un \u00e9v\u00e9nement Remarquez la richesse de cette piste d’audit : vous pouvez voir le d\u00e9p\u00f4t exact, la branche, le SHA du commit, l’utilisateur GitHub qui a d\u00e9clench\u00e9 le workflow, et le nom du workflow. C’est bien plus d\u00e9taill\u00e9 que ce que vous obtenez avec des credentials d’utilisateur IAM statiques.<\/p>\n Les appels Utilisez CloudTrail Lake ou Athena pour interroger les mod\u00e8les d’acc\u00e8s historiques :<\/p>\n Cela vous donne un d\u00e9compte de fr\u00e9quence des d\u00e9p\u00f4ts et branches qui se sont authentifi\u00e9s via OIDC \u2014 essentiel pour les revues d’acc\u00e8s et les audits de conformit\u00e9.<\/p>\n C’est l’exercice le plus important de tout le lab. La migration des credentials statiques vers OIDC est incompl\u00e8te \u2014 et votre posture de s\u00e9curit\u00e9 n’est pas am\u00e9lior\u00e9e \u2014 tant que les anciennes cl\u00e9s d’acc\u00e8s n’ont pas \u00e9t\u00e9 supprim\u00e9es. Tant que les deux m\u00e9thodes d’authentification coexistent, un attaquant peut toujours utiliser les cl\u00e9s statiques.<\/p>\n Supprimez les anciens secrets de votre d\u00e9p\u00f4t GitHub :<\/p>\n V\u00e9rifiez qu’ils ont \u00e9t\u00e9 supprim\u00e9s :<\/p>\n Vous ne devriez plus voir AWS_ACCESS_KEY_ID<\/code> et AWS_SECRET_ACCESS_KEY<\/code> stock\u00e9s comme secrets de d\u00e9p\u00f4t, vous avez un s\u00e9rieux probl\u00e8me de s\u00e9curit\u00e9. Ces credentials \u00e0 longue dur\u00e9e de vie n’expirent jamais d’eux-m\u00eames, peuvent \u00eatre exfiltr\u00e9s par n’importe quelle \u00e9tape du workflow (y compris les actions tierces), et donnent aux attaquants un acc\u00e8s persistant \u00e0 votre compte AWS en cas de compromission.<\/p>\n\n
Pr\u00e9requis<\/h2>\n
\n
aws --version<\/code> doit retourner 2.x)<\/li>\nConfiguration de l’environnement : la base non s\u00e9curis\u00e9e<\/h2>\n
\u00c9tape 1 : Cr\u00e9er un d\u00e9p\u00f4t de test<\/h3>\n
oidc-lab<\/code>. Initialisez-le avec un README et clonez-le localement :<\/p>\ngh repo create oidc-lab --public --clone\ncd oidc-lab<\/code><\/pre>\n\u00c9tape 2 : Stocker les credentials AWS comme secrets GitHub (la m\u00e9thode non s\u00e9curis\u00e9e)<\/h3>\n
gh secret set AWS_ACCESS_KEY_ID --body \"AKIAIOSFODNN7EXAMPLE\"\ngh secret set AWS_SECRET_ACCESS_KEY --body \"wJalrXUtnFEMI\/K7MDENG\/bPxRfiCYEXAMPLEKEY\"<\/code><\/pre>\n\n
\u00c9tape 3 : Cr\u00e9er le workflow de base non s\u00e9curis\u00e9<\/h3>\n
.github\/workflows\/deploy.yml<\/code> avec des credentials statiques :<\/p>\nname: Deploy (Insecure - Static Keys)\n\non:\n push:\n branches: [main]\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout\n uses: actions\/checkout@v4\n\n - name: Configure AWS Credentials (INSECURE)\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}\n aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}\n aws-region: us-east-1\n\n - name: Verify Identity\n run: aws sts get-caller-identity\n\n - name: List S3 Buckets\n run: aws s3 ls<\/code><\/pre>\nExercice 1 : Cr\u00e9er le fournisseur d’identit\u00e9 OIDC dans AWS<\/h2>\n
Option A : Console AWS<\/h3>\n
\n
https:\/\/token.actions.githubusercontent.com<\/code><\/li>\nsts.amazonaws.com<\/code><\/li>\nOption B : AWS CLI<\/h3>\n
# Obtenir l'empreinte du fournisseur OIDC de GitHub\n# Depuis 2024, l'empreinte de GitHub est g\u00e9r\u00e9e par AWS et auto-v\u00e9rifi\u00e9e\n# Vous pouvez la r\u00e9cup\u00e9rer avec :\nTHUMBPRINT=$(openssl s_client -servername token.actions.githubusercontent.com \\\n -showcerts -connect token.actions.githubusercontent.com:443 < \/dev\/null 2>\/dev\/null \\\n | openssl x509 -fingerprint -noout \\\n | cut -d'=' -f2 \\\n | tr -d ':' \\\n | tr '[:upper:]' '[:lower:]')\n\naws iam create-open-id-connect-provider \\\n --url https:\/\/token.actions.githubusercontent.com \\\n --client-id-list sts.amazonaws.com \\\n --thumbprint-list \"$THUMBPRINT\"<\/code><\/pre>\nOption C : Terraform<\/h3>\n
resource \"aws_iam_openid_connect_provider\" \"github\" {\n url = \"https:\/\/token.actions.githubusercontent.com\"\n client_id_list = [\"sts.amazonaws.com\"]\n thumbprint_list = [\"6938fd4d98bab03faadb97b34396831e3780aea1\"]\n\n tags = {\n Name = \"GitHub Actions OIDC\"\n Environment = \"shared\"\n ManagedBy = \"terraform\"\n }\n}<\/code><\/pre>\nV\u00e9rification<\/h3>\n
aws iam list-open-id-connect-providers<\/code><\/pre>\narn:aws:iam::123456789012:oidc-provider\/token.actions.githubusercontent.com<\/code><\/pre>\nExercice 2 : Cr\u00e9er le r\u00f4le IAM avec la politique de confiance<\/h2>\n
\u00c9tape 1 : Cr\u00e9er la politique de confiance<\/h3>\n
trust-policy.json<\/code>. Remplacez 123456789012<\/code> par votre ID de compte AWS, et myorg\/myrepo<\/code> par votre organisation et d\u00e9p\u00f4t GitHub :<\/p>\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Principal\": {\n \"Federated\": \"arn:aws:iam::123456789012:oidc-provider\/token.actions.githubusercontent.com\"\n },\n \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n \"Condition\": {\n \"StringEquals\": {\n \"token.actions.githubusercontent.com:aud\": \"sts.amazonaws.com\"\n },\n \"StringLike\": {\n \"token.actions.githubusercontent.com:sub\": \"repo:myorg\/myrepo:ref:refs\/heads\/main\"\n }\n }\n }\n ]\n}<\/code><\/pre>\nComprendre les champs de la politique de confiance<\/h3>\n
\n
Principal.Federated<\/code><\/strong> \u2014 L’ARN du fournisseur OIDC GitHub que vous avez cr\u00e9\u00e9 dans l’exercice 1. Cela indique \u00e0 AWS quel fournisseur d’identit\u00e9 approuver.<\/li>\nAction: sts:AssumeRoleWithWebIdentity<\/code><\/strong> \u2014 L’action STS sp\u00e9cifique pour la f\u00e9d\u00e9ration OIDC. Elle est diff\u00e9rente de sts:AssumeRole<\/code> (utilis\u00e9e pour les r\u00f4les inter-comptes) ou sts:AssumeRoleWithSAML<\/code> (utilis\u00e9e pour la f\u00e9d\u00e9ration SAML).<\/li>\nCondition.StringEquals.aud<\/code><\/strong> \u2014 Valide le claim d’audience dans le jeton OIDC. Cela doit \u00eatre sts.amazonaws.com<\/code> pour correspondre \u00e0 ce que l’action configure-aws-credentials<\/code> envoie.<\/li>\nCondition.StringLike.sub<\/code><\/strong> \u2014 Valide le claim de sujet. C’est le contr\u00f4le de s\u00e9curit\u00e9 le plus important. Le sujet contient le d\u00e9p\u00f4t, le type de ref et la valeur de ref. L’utilisation de StringLike<\/code> avec des caract\u00e8res g\u00e9n\u00e9riques permet une correspondance flexible, tandis que StringEquals<\/code> exige une correspondance exacte.<\/li>\n<\/ul>\n\u00c9tape 2 : Cr\u00e9er le r\u00f4le IAM<\/h3>\n
aws iam create-role \\\n --role-name github-actions-deploy \\\n --assume-role-policy-document file:\/\/trust-policy.json \\\n --description \"Role for GitHub Actions OIDC deployment\" \\\n --max-session-duration 3600<\/code><\/pre>\n\u00c9tape 3 : Attacher une politique IAM minimale<\/h3>\n
{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Action\": [\n \"s3:GetObject\",\n \"s3:ListBucket\"\n ],\n \"Resource\": [\n \"arn:aws:s3:::my-deployment-bucket\",\n \"arn:aws:s3:::my-deployment-bucket\/*\"\n ]\n }\n ]\n}<\/code><\/pre>\n# Enregistrez ce qui pr\u00e9c\u00e8de dans permissions-policy.json, puis :\naws iam put-role-policy \\\n --role-name github-actions-deploy \\\n --policy-name S3ReadAccess \\\n --policy-document file:\/\/permissions-policy.json<\/code><\/pre>\n\u00c9quivalent Terraform<\/h3>\n
data \"aws_iam_policy_document\" \"github_actions_trust\" {\n statement {\n effect = \"Allow\"\n actions = [\"sts:AssumeRoleWithWebIdentity\"]\n\n principals {\n type = \"Federated\"\n identifiers = [aws_iam_openid_connect_provider.github.arn]\n }\n\n condition {\n test = \"StringEquals\"\n variable = \"token.actions.githubusercontent.com:aud\"\n values = [\"sts.amazonaws.com\"]\n }\n\n condition {\n test = \"StringLike\"\n variable = \"token.actions.githubusercontent.com:sub\"\n values = [\"repo:myorg\/myrepo:ref:refs\/heads\/main\"]\n }\n }\n}\n\nresource \"aws_iam_role\" \"github_actions_deploy\" {\n name = \"github-actions-deploy\"\n assume_role_policy = data.aws_iam_policy_document.github_actions_trust.json\n max_session_duration = 3600\n\n tags = {\n Name = \"GitHub Actions Deploy\"\n ManagedBy = \"terraform\"\n }\n}\n\nresource \"aws_iam_role_policy\" \"s3_read\" {\n name = \"S3ReadAccess\"\n role = aws_iam_role.github_actions_deploy.id\n\n policy = jsonencode({\n Version = \"2012-10-17\"\n Statement = [\n {\n Effect = \"Allow\"\n Action = [\n \"s3:GetObject\",\n \"s3:ListBucket\"\n ]\n Resource = [\n \"arn:aws:s3:::my-deployment-bucket\",\n \"arn:aws:s3:::my-deployment-bucket\/*\"\n ]\n }\n ]\n })\n}<\/code><\/pre>\nV\u00e9rification<\/h3>\n
# Confirmez que le r\u00f4le existe et poss\u00e8de la bonne politique de confiance\naws iam get-role --role-name github-actions-deploy \\\n --query 'Role.AssumeRolePolicyDocument' --output json<\/code><\/pre>\nExercice 3 : Mettre \u00e0 jour le workflow GitHub Actions<\/h2>\n
\u00c9tape 1 : Mettre \u00e0 jour le workflow<\/h3>\n
.github\/workflows\/deploy.yml<\/code> par ce qui suit :<\/p>\nname: Deploy (Secure - OIDC)\n\non:\n push:\n branches: [main]\n\npermissions:\n id-token: write # Requis pour la demande de jeton OIDC\n contents: read # Requis pour actions\/checkout\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout\n uses: actions\/checkout@v4\n\n - name: Configure AWS Credentials via OIDC\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789012:role\/github-actions-deploy\n role-session-name: github-actions-${{ github.run_id }}\n aws-region: us-east-1\n\n - name: Verify Identity\n run: |\n aws sts get-caller-identity\n echo \"Successfully authenticated via OIDC!\"\n\n - name: List S3 Bucket Contents\n run: aws s3 ls s3:\/\/my-deployment-bucket\/<\/code><\/pre>\nChangements cl\u00e9s expliqu\u00e9s<\/h3>\n
\n
permissions: id-token: write<\/code><\/strong> \u2014 C’est obligatoire. Cela accorde au workflow la permission de demander un jeton OIDC aupr\u00e8s du fournisseur d’identit\u00e9 de GitHub. Sans cela, l’action configure-aws-credentials<\/code> ne peut pas obtenir de jeton.<\/li>\npermissions: contents: read<\/code><\/strong> \u2014 Lorsque vous d\u00e9finissez une permission explicite, toutes les autres permissions sont par d\u00e9faut \u00e0 none<\/code>. Vous devez explicitement accorder contents: read<\/code> pour que actions\/checkout<\/code> fonctionne.<\/li>\nrole-to-assume<\/code><\/strong> \u2014 L’ARN du r\u00f4le IAM cr\u00e9\u00e9 dans l’exercice 2. L’action appellera sts:AssumeRoleWithWebIdentity<\/code> en utilisant le jeton OIDC.<\/li>\nrole-session-name<\/code><\/strong> \u2014 Un nom de session descriptif qui appara\u00eet dans CloudTrail. Inclure le github.run_id<\/code> rend chaque session tra\u00e7able jusqu’\u00e0 une ex\u00e9cution de workflow sp\u00e9cifique.<\/li>\naws-access-key-id<\/code> ni aws-secret-access-key<\/code><\/strong> \u2014 Ces champs sont compl\u00e8tement supprim\u00e9s. L’action d\u00e9tecte que role-to-assume<\/code> est d\u00e9fini sans credentials statiques et utilise automatiquement OIDC.<\/li>\n<\/ul>\n\u00c9tape 2 : Pousser et v\u00e9rifier<\/h3>\n
git add .github\/workflows\/deploy.yml\ngit commit -m \"Migrate to OIDC authentication\"\ngit push origin main<\/code><\/pre>\n{\n \"UserId\": \"AROA3XFRBF23ZCEXAMPLE:github-actions-9876543210\",\n \"Account\": \"123456789012\",\n \"Arn\": \"arn:aws:sts::123456789012:assumed-role\/github-actions-deploy\/github-actions-9876543210\"\n}<\/code><\/pre>\nassumed-role\/github-actions-deploy<\/code> \u2014 cela confirme que le workflow s’authentifie via le r\u00f4le OIDC, et non via un utilisateur IAM.<\/p>\nExercice 4 : Restreindre par branche, environnement et tag<\/h2>\n
sub<\/code> de la politique de confiance est votre m\u00e9canisme principal de contr\u00f4le d’acc\u00e8s. Le claim de sujet de GitHub Actions suit un format pr\u00e9visible qui encode le d\u00e9p\u00f4t, le type de d\u00e9clencheur et la ref.<\/p>\nMod\u00e8les courants de claims de sujet<\/h3>\n
\n\n
\n \nD\u00e9clencheur<\/th>\n Format du claim de sujet<\/th>\n<\/tr>\n<\/thead>\n \n Push vers une branche<\/td>\n repo:OWNER\/REPO:ref:refs\/heads\/BRANCH<\/code><\/td>\n<\/tr>\n\n Pull request<\/td>\n repo:OWNER\/REPO:pull_request<\/code><\/td>\n<\/tr>\n\n Environnement<\/td>\n repo:OWNER\/REPO:environment:ENV_NAME<\/code><\/td>\n<\/tr>\n\n Push de tag<\/td>\n repo:OWNER\/REPO:ref:refs\/tags\/TAG<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nRestriction \u00e0 la branche main uniquement<\/h3>\n
main<\/code> peuvent assumer le r\u00f4le :<\/p>\n\"StringLike\": {\n \"token.actions.githubusercontent.com:sub\": \"repo:myorg\/myrepo:ref:refs\/heads\/main\"\n}<\/code><\/pre>\nRestriction \u00e0 un environnement sp\u00e9cifique<\/h3>\n
environment<\/code>, le claim de sujet change pour inclure le nom de l’environnement :<\/p>\n\"StringLike\": {\n \"token.actions.githubusercontent.com:sub\": \"repo:myorg\/myrepo:environment:production\"\n}<\/code><\/pre>\nRestriction aux releases tagg\u00e9es<\/h3>\n
v1.0.0<\/code>, v2.3.1<\/code>) \u00e0 assumer le r\u00f4le :<\/p>\n\"StringLike\": {\n \"token.actions.githubusercontent.com:sub\": \"repo:myorg\/myrepo:ref:refs\/tags\/v*\"\n}<\/code><\/pre>\nTester les restrictions<\/h3>\n
git checkout -b feature\/test-oidc-restriction\ngit commit --allow-empty -m \"Test OIDC restriction\"\ngit push origin feature\/test-oidc-restriction<\/code><\/pre>\nrefs\/heads\/main<\/code>, le workflow sur la branche de fonctionnalit\u00e9 \u00e9chouera avec :<\/p>\nError: Could not assume role with OIDC: Not authorized to perform\nsts:AssumeRoleWithWebIdentity\n\nAccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity<\/code><\/pre>\nmain<\/code> :<\/p>\ngit checkout main\ngit merge feature\/test-oidc-restriction\ngit push origin main<\/code><\/pre>\nmain<\/code> r\u00e9ussit. Cela d\u00e9montre le contr\u00f4le d’acc\u00e8s bas\u00e9 sur les claims<\/strong> \u2014 la politique de confiance AWS \u00e9value les claims int\u00e9gr\u00e9s dans le jeton OIDC pour prendre des d\u00e9cisions d’autorisation. Aucun credential n’est impliqu\u00e9 ; le jeton lui-m\u00eame porte le contexte d’autorisation.<\/p>\nExercice 5 : R\u00f4les par environnement<\/h2>\n
\u00c9tape 1 : Cr\u00e9er les environnements GitHub<\/h3>\n
\n
\n
main<\/code> uniquement<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\u00c9tape 2 : Cr\u00e9er le r\u00f4le IAM de staging<\/h3>\n
{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Principal\": {\n \"Federated\": \"arn:aws:iam::123456789012:oidc-provider\/token.actions.githubusercontent.com\"\n },\n \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n \"Condition\": {\n \"StringEquals\": {\n \"token.actions.githubusercontent.com:aud\": \"sts.amazonaws.com\"\n },\n \"StringLike\": {\n \"token.actions.githubusercontent.com:sub\": \"repo:myorg\/myrepo:*\"\n }\n }\n }\n ]\n}<\/code><\/pre>\naws iam create-role \\\n --role-name github-actions-staging \\\n --assume-role-policy-document file:\/\/staging-trust-policy.json \\\n --description \"Staging deployment role - all branches\"<\/code><\/pre>\n\u00c9tape 3 : Cr\u00e9er le r\u00f4le IAM de production<\/h3>\n
production<\/code> sur la branche main<\/code> :<\/p>\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Principal\": {\n \"Federated\": \"arn:aws:iam::123456789012:oidc-provider\/token.actions.githubusercontent.com\"\n },\n \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n \"Condition\": {\n \"StringEquals\": {\n \"token.actions.githubusercontent.com:aud\": \"sts.amazonaws.com\",\n \"token.actions.githubusercontent.com:sub\": \"repo:myorg\/myrepo:environment:production\"\n }\n }\n }\n ]\n}<\/code><\/pre>\naws iam create-role \\\n --role-name github-actions-production \\\n --assume-role-policy-document file:\/\/production-trust-policy.json \\\n --description \"Production deployment role - main branch + production environment only\"<\/code><\/pre>\n\u00c9tape 4 : Workflow multi-environnement<\/h3>\n
name: Deploy Multi-Environment\n\non:\n push:\n branches: [main]\n\npermissions:\n id-token: write\n contents: read\n\njobs:\n deploy-staging:\n runs-on: ubuntu-latest\n environment: staging\n steps:\n - name: Checkout\n uses: actions\/checkout@v4\n\n - name: Configure AWS Credentials (Staging)\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789012:role\/github-actions-staging\n role-session-name: staging-${{ github.run_id }}\n aws-region: us-east-1\n\n - name: Deploy to Staging\n run: |\n aws sts get-caller-identity\n echo \"Deploying to staging environment...\"\n # Your staging deployment commands here\n\n deploy-production:\n runs-on: ubuntu-latest\n needs: deploy-staging\n environment: production\n steps:\n - name: Checkout\n uses: actions\/checkout@v4\n\n - name: Configure AWS Credentials (Production)\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789012:role\/github-actions-production\n role-session-name: production-${{ github.run_id }}\n aws-region: us-east-1\n\n - name: Deploy to Production\n run: |\n aws sts get-caller-identity\n echo \"Deploying to production environment...\"\n # Your production deployment commands here<\/code><\/pre>\n\n
github-actions-staging<\/code>, et d\u00e9ploie<\/li>\ngithub-actions-production<\/code>, et d\u00e9ploie<\/li>\n<\/ol>\nStringEquals<\/code> (et non StringLike<\/code>) avec le sujet exact repo:myorg\/myrepo:environment:production<\/code>. Cela signifie que seuls les jobs qui d\u00e9clarent environment: production<\/code> peuvent assumer le r\u00f4le de production \u2014 et les environnements GitHub imposent que seuls les d\u00e9ploiements depuis la branche main<\/code> avec approbation d’un r\u00e9viseur peuvent utiliser cet environnement.<\/p>\nTerraform pour les deux r\u00f4les<\/h3>\n
locals {\n github_oidc_arn = aws_iam_openid_connect_provider.github.arn\n github_repo = \"myorg\/myrepo\"\n}\n\n# R\u00f4le staging - fait confiance \u00e0 toutes les branches\nresource \"aws_iam_role\" \"github_actions_staging\" {\n name = \"github-actions-staging\"\n\n assume_role_policy = jsonencode({\n Version = \"2012-10-17\"\n Statement = [\n {\n Effect = \"Allow\"\n Principal = {\n Federated = local.github_oidc_arn\n }\n Action = \"sts:AssumeRoleWithWebIdentity\"\n Condition = {\n StringEquals = {\n \"token.actions.githubusercontent.com:aud\" = \"sts.amazonaws.com\"\n }\n StringLike = {\n \"token.actions.githubusercontent.com:sub\" = \"repo:${local.github_repo}:*\"\n }\n }\n }\n ]\n })\n}\n\n# R\u00f4le production - fait confiance uniquement \u00e0 l'environnement production\nresource \"aws_iam_role\" \"github_actions_production\" {\n name = \"github-actions-production\"\n\n assume_role_policy = jsonencode({\n Version = \"2012-10-17\"\n Statement = [\n {\n Effect = \"Allow\"\n Principal = {\n Federated = local.github_oidc_arn\n }\n Action = \"sts:AssumeRoleWithWebIdentity\"\n Condition = {\n StringEquals = {\n \"token.actions.githubusercontent.com:aud\" = \"sts.amazonaws.com\"\n \"token.actions.githubusercontent.com:sub\" = \"repo:${local.github_repo}:environment:production\"\n }\n }\n }\n ]\n })\n}<\/code><\/pre>\nExercice 6 : V\u00e9rifier et auditer<\/h2>\n
AssumeRoleWithWebIdentity<\/code> est journalis\u00e9 avec l’ensemble complet des claims OIDC de GitHub.<\/p>\n\u00c9tape 1 : Interroger CloudTrail pour les \u00e9v\u00e9nements OIDC<\/h3>\n
aws cloudtrail lookup-events \\\n --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity \\\n --max-results 10 \\\n --query 'Events[].{Time:EventTime,Username:Username,Resources:Resources}' \\\n --output table<\/code><\/pre>\n\u00c9tape 2 : Examiner l’\u00e9v\u00e9nement CloudTrail<\/h3>\n
AssumeRoleWithWebIdentity<\/code> typique dans CloudTrail contient les champs cl\u00e9s suivants :<\/p>\n{\n \"eventName\": \"AssumeRoleWithWebIdentity\",\n \"eventSource\": \"sts.amazonaws.com\",\n \"requestParameters\": {\n \"roleArn\": \"arn:aws:iam::123456789012:role\/github-actions-deploy\",\n \"roleSessionName\": \"github-actions-9876543210\"\n },\n \"requestID\": \"a1b2c3d4-e5f6-7890-abcd-ef1234567890\",\n \"responseElements\": {\n \"credentials\": {\n \"accessKeyId\": \"ASIAEXAMPLE...\",\n \"expiration\": \"Mar 23, 2026 2:00:00 PM\"\n },\n \"subjectFromWebIdentityToken\": \"repo:myorg\/myrepo:ref:refs\/heads\/main\",\n \"provider\": \"arn:aws:iam::123456789012:oidc-provider\/token.actions.githubusercontent.com\"\n },\n \"additionalEventData\": {\n \"WebIdFederationData\": {\n \"federatedProvider\": \"arn:aws:iam::123456789012:oidc-provider\/token.actions.githubusercontent.com\",\n \"attributes\": {\n \"sub\": \"repo:myorg\/myrepo:ref:refs\/heads\/main\",\n \"aud\": \"sts.amazonaws.com\",\n \"iss\": \"https:\/\/token.actions.githubusercontent.com\",\n \"repository\": \"myorg\/myrepo\",\n \"ref\": \"refs\/heads\/main\",\n \"sha\": \"abc123def456...\",\n \"actor\": \"github-username\",\n \"workflow\": \"Deploy (Secure - OIDC)\",\n \"run_id\": \"9876543210\"\n }\n }\n }\n}<\/code><\/pre>\n\u00c9tape 3 : Cr\u00e9er une alarme CloudWatch pour les tentatives \u00e9chou\u00e9es d’AssumeRole<\/h3>\n
AssumeRoleWithWebIdentity<\/code> \u00e9chou\u00e9s peuvent indiquer des tentatives d’acc\u00e8s non autoris\u00e9es ou des politiques de confiance mal configur\u00e9es. Configurez un filtre de m\u00e9triques et une alarme :<\/p>\n# Cr\u00e9er un filtre de m\u00e9triques CloudWatch Logs pour les AssumeRoleWithWebIdentity \u00e9chou\u00e9s\naws logs put-metric-filter \\\n --log-group-name CloudTrail\/DefaultLogGroup \\\n --filter-name FailedOIDCAssumeRole \\\n --filter-pattern '{ ($.eventName = \"AssumeRoleWithWebIdentity\") && ($.errorCode = \"AccessDenied\") }' \\\n --metric-transformations \\\n metricName=FailedOIDCAssumeRoleCount,metricNamespace=SecurityMetrics,metricValue=1\n\n# Cr\u00e9er une alarme CloudWatch qui se d\u00e9clenche quand les \u00e9checs d\u00e9passent le seuil\naws cloudwatch put-metric-alarm \\\n --alarm-name FailedOIDCAssumeRole \\\n --alarm-description \"Alert on failed OIDC AssumeRoleWithWebIdentity attempts\" \\\n --metric-name FailedOIDCAssumeRoleCount \\\n --namespace SecurityMetrics \\\n --statistic Sum \\\n --period 300 \\\n --threshold 3 \\\n --comparison-operator GreaterThanOrEqualToThreshold \\\n --evaluation-periods 1 \\\n --alarm-actions arn:aws:sns:us-east-1:123456789012:security-alerts \\\n --treat-missing-data notBreaching<\/code><\/pre>\n\u00c9tape 4 : Auditer quels d\u00e9p\u00f4ts et branches ont acc\u00e9d\u00e9 au r\u00f4le<\/h3>\n
# Utiliser CloudTrail lookup pour trouver toutes les authentifications OIDC des derni\u00e8res 24 heures\naws cloudtrail lookup-events \\\n --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity \\\n --start-time $(date -u -d '24 hours ago' '+%Y-%m-%dT%H:%M:%SZ' 2>\/dev\/null || date -u -v-24H '+%Y-%m-%dT%H:%M:%SZ') \\\n --end-time $(date -u '+%Y-%m-%dT%H:%M:%SZ') \\\n --query 'Events[].CloudTrailEvent' \\\n --output text | jq -r '.responseElements.subjectFromWebIdentityToken \/\/ \"N\/A\"' | sort | uniq -c | sort -rn<\/code><\/pre>\nExercice 7 : Supprimer les anciennes cl\u00e9s d’acc\u00e8s<\/h2>\n
\u00c9tape 1 : Supprimer les secrets GitHub<\/h3>\n
gh secret delete AWS_ACCESS_KEY_ID --repo myorg\/myrepo\ngh secret delete AWS_SECRET_ACCESS_KEY --repo myorg\/myrepo<\/code><\/pre>\ngh secret list --repo myorg\/myrepo<\/code><\/pre>\nAWS_ACCESS_KEY_ID<\/code> ni