GitHub Actions uten AWS-nøkler: en for bred trust policy åpner kontoen

La GitHub Actions bruke OIDC til å overta en IAM-rolle i AWS: registrer GitHub som identitetsleverandør, avgrens rollens trust policy til riktig repository og gren, og gi jobben tillatelsen id-token: write. GitHubs OIDC-veiledning beskriver hvordan arbeidsflyten får AWS-tilgang uten langsiktige tilgangsnøkler lagret som GitHub-secrets.

Avgrensningen i trust policy er avgjørende. Hvis sub-vilkåret også passer arbeidsflyter i andre repositories, kan de overta samme rolle og bruke AWS-tillatelsene den har fått. Tilgangen gjelder rollens rettigheter i kontoen; hvor omfattende den blir, avhenger derfor både av hvem som kan overta rollen og av tillatelsespolicyen som er knyttet til den.

Opprett OIDC-leverandøren og IAM-rollen

Legg til en OpenID Connect-leverandør i AWS IAM med URL-en https://token.actions.githubusercontent.com og audience sts.amazonaws.com. Opprett deretter en rolle for webidentitet som stoler på denne leverandøren gjennom sts:AssumeRoleWithWebIdentity. Audience-verdien må stemme med tokenet som arbeidsflyten ber om; configure-aws-credentials bruker sts.amazonaws.com som standard for vanlig AWS.

Rollen har to forskjellige kontrollpunkter. Trust policy bestemmer hvilken GitHub-kjøring som får overta den, mens en separat tillatelsespolicy bestemmer hvilke AWS-handlinger kjøringen kan utføre etterpå. Du kan opprette rollen uten ressurstillatelser mens du kontrollerer identiteten, og deretter gi den bare tillatelsene utrullingen trenger. En snever tillatelsespolicy begrenser følgene av en feil i trust policy, men erstatter ikke en presis avgrensning av hvem som får overta rollen.

Bind trust policy til repository og gren

AWS’ IAM-veiledning krever et sub-vilkår for roller som stoler på GitHubs OIDC-leverandør; verdien kan ikke være tom eller bare et jokertegn. AWS advarer om at manglende avgrensning til en organisasjon eller et repository kan la arbeidsflyter utenfor din kontroll overta rollen. For én godkjent gren i ett repository er StringEquals med hele subject-verdien et tydelig valg.

Dette er et fiktivt eksempel for grenen main i eksempelorg/appen. Kontonummeret og de numeriske GitHub-ID-ene er plassholdere. Erstatt dem med verdiene for din AWS-konto og ditt repository før policyen tas i bruk:

{"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:eksempelorg@123456/appen@789012:ref:refs/heads/main"}}}]}

aud angir hvem tokenet er ment for, og må her være sts.amazonaws.com. sub angir GitHub-konteksten som skal få rollen: organisasjonen, repositoryet og grenen main. StringEquals krever at hele verdien stemmer. Med ID-formatet i eksemplet ville et bredere StringLike-vilkår som repo:eksempelorg@123456/* omfatte flere repositories i organisasjonen. Det kan gi arbeidsflyter der de samme rolletillatelsene selv om arbeidsflyten du opprinnelig satte opp, bare kjører fra main.

Subject-formatet må passe repositoryet ditt. Noen repositories sender navn uten numeriske ID-er, mens andre legger varige organisasjons- og repository-ID-er etter navnene. En policy med ID-er avviser et token uten dem, og omvendt. Bruk den faktiske formen som GitHub sender; ikke utvid vilkåret med jokertegn bare for å få et avvist kall gjennom.

Legg inn en minimal arbeidsflyt

Opprett filen .github/workflows/aws-identitet.yml i repositoryet. Dokumentasjonen for configure-aws-credentials viser OIDC-basert rolleantakelse, subject-formatene og action-versjonen v6.3.0 som brukes nedenfor. Rolle-ARN-en og kontonummeret i dette eksemplet er fiktive:

name: Kontroller AWS-identitet

on: {push: {branches: [main]}}

jobs:

  verify:

    runs-on: ubuntu-latest

    permissions: {id-token: write}

    steps:

      - uses: aws-actions/[email protected]

        with:

          role-to-assume: arn:aws:iam::123456789012:role/github-oidc-main

          aws-region: eu-west-1

      - run: aws sts get-caller-identity

Utløseren kjører denne arbeidsflyten ved push til main, og id-token: write lar jobben be GitHub om et OIDC-token. Handlingen veksler tokenet mot kortlivede AWS-legitimasjoner for de neste stegene. Ingen kode sjekkes ut i eksemplet, så jobben trenger heller ikke contents-tillatelse. Selve trust policyen kjenner likevel ikke navnet på denne workflow-filen: en annen jobb i samme repository på main kan også passe sub-vilkåret hvis den får be om et OIDC-token.

Kontroller rollen før du gir den ressurstilgang

La aws sts get-caller-identity være siste steg i den første kjøringen. I svaret skal Account være kontoen du forventer, mens Arn skal vise en antatt økt for den tiltenkte rollen. Kommandoen viser hvilken AWS-identitet jobben faktisk fikk. Den prøver ikke en senere utrulling og sier derfor ingenting om hvorvidt tillatelsespolicyen gir tilgang til de ressursene utrullingen skal endre.

Hvis rolleantakelsen feiler, sammenlign først leverandørens URL og audience med verdiene i IAM. Kontroller så at jobben har id-token: write, at role-to-assume peker på riktig rolle, og at sub-vilkåret samsvarer nøyaktig med subject for den aktuelle kjøringen. Feil gren, et annet repository eller forskjellen mellom subject med og uten numeriske ID-er er nok til at StringEquals avviser tokenet. Løs årsaken i vilkåret eller arbeidsflyten før du legger til AWS-kommandoer som endrer ressurser.

Når GitHub environment endrer subject

Legger du environment: prod til jobben, endres subject fra en grenverdi som slutter på :ref:refs/heads/main til en environment-verdi som slutter på :environment:prod. I det fiktive ID-baserte eksemplet blir hele verdien repo:eksempelorg@123456/appen@789012:environment:prod. Trust policyen ovenfor vil da avvise jobben fordi den fortsatt krever grenverdien. En policy for environment må bruke den nye, eksakte verdien.

Når subject viser environment-navnet, gir det vanlige sub-vilkåret ikke lenger den samme kontrollen av grenen. Sett derfor beskyttelsesregler på GitHub-environmentet prod som begrenser hvilke grener og tagger som kan bruke det. Kontroller samtidig om repositoryet sender subject med eller uten numeriske ID-er; også environment-verdien må følge den formen. Da kan rollen avgrenses til det faktiske environmentet uten å åpne for flere repositories for å omgå en formatfeil.

Les også:

• Maskinporten uten client secret: slik setter du opp første API-klient