GitHub Actions bez AWS klíčů: OIDC funguje jen s přesnou podmínkou sub

GitHub Actions mohou nasazovat do AWS bez dlouhodobého přístupového klíče v GitHub Secrets. Podle návodu GitHubu k OIDC v AWS workflow získá token, kterým převezme IAM roli a obdrží dočasné přihlašovací údaje. Pro bezpečné nasazení musí důvěryhodná zásada role porovnat claim sub s identitou zamýšleného repozitáře a větve nebo prostředí.

Postup má dvě části: v AWS vytvořit poskytovatele identity a roli s úzkou důvěrou, v GitHub Actions povolit vyžádání tokenu a použít roli místo statických klíčů. Pokud úloha používá GitHub Environment, její sub má jiný tvar než při nasazení přímo z větve. Tuto hodnotu je nutné promítnout do zásady IAM i do pravidel prostředí.

Vytvořte poskytovatele identity a IAM roli

V konzoli AWS IAM otevřete Identity providers a přidejte poskytovatele typu OpenID Connect. URL poskytovatele je https://token.actions.githubusercontent.com; pro oficiální akci konfigurující přihlašovací údaje AWS zadejte jako audience sts.amazonaws.com. Pokud tento poskytovatel v účtu již existuje, použijte jej při vytváření role. V části Roles vytvořte roli pro Web identity a vyberte poskytovatele GitHubu.

Roli nastavte dvě oddělené zásady. Důvěryhodná zásada určuje, které tokeny smějí roli převzít; zásada oprávnění vymezuje operace a prostředky AWS dostupné po jejím převzetí. Pro pouhé ověření identity není třeba přidělit nasazovací oprávnění. Až připojíte skutečný nasazovací krok, povolte mu pouze operace nad prostředky, které používá.

Při vytváření role v konzoli zkontrolujte výslednou důvěryhodnou zásadu. Pole pro repozitář a větev mohou být volitelná a jejich vynechání vede k širšímu vzoru. Údaj, že role důvěřuje GitHubu, sám neříká, který repozitář ji může převzít.

Omezte podmínku sub na větev nebo Environment

Dokumentace AWS k roli pro GitHub OIDC požaduje podmínku sub, jejíž hodnotou není pouze zástupný znak, a doporučuje ji omezit na konkrétní repozitáře či větve. To je technické minimum pro uložení zásady. Pro nasazovací roli určenou jedné větvi použijte StringEquals s její přesnou hodnotou; vzor pro celý repozitář by připustil i jiné větve a prostředí.

Následující důvěryhodná zásada je podmíněný příklad pro účet 123456789012, repozitář firma/aplikace a větev main. Před použitím nahraďte číslo účtu, názvy i hodnotu sub podle svého repozitáře:

{"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:firma/aplikace:ref:refs/heads/main"}}}]}

Pro úlohu používající GitHub Environment s podmíněným názvem produkce nahraďte hodnotu sub řetězcem repo:firma/aplikace:environment:produkce. Environmentová hodnota už neobsahuje větev. V nastavení tohoto prostředí proto omezte, které větve do něj smějí nasazovat; podle způsobu nasazování můžete přidat i schvalování. Omezení události workflow na main samo nenahrazuje pravidla prostředí.

Zkontrolujte také formát identity svého repozitáře. Některé repozitáře mají v sub za jménem vlastníka a repozitáře neměnná ID oddělená znakem @. Pro takový repozitář by zásada uvedená výše přístup odmítla: do podmínky patří přesná skutečná hodnota včetně těchto ID a správného zakončení pro větev či Environment. Rozdíl neopravujte rozšířením podmínky na všechny repozitáře organizace.

Spusťte workflow s dočasnými přihlašovacími údaji

Do souboru .github/workflows/aws-oidc.yml vložte následující ukázkové workflow. Účet, roli a region upravte podle svého nasazení; předpokládá se větev main a odpovídající podmínka sub v IAM. Každý z následujících řádků patří do téhož souboru:

name: Ověření AWS OIDC

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

permissions: {id-token: write}

jobs:

  overeni:

    runs-on: ubuntu-latest

    steps:

      - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502

        with:

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

          aws-region: eu-central-1

      - run: aws sts get-caller-identity

Oprávnění id-token: write dovoluje úloze vyžádat OIDC token; samo jí nedává právo zapisovat do AWS. Akce configure-aws-credentials použije token k převzetí role a připraví dočasné údaje pro následující krok. Výstup get-caller-identity má ukázat očekávaný účet a převzatou roli. Toto ověření nevyžaduje hodnoty AWS_ACCESS_KEY_ID ani AWS_SECRET_ACCESS_KEY v Secrets.

Pro variantu s Environment přidejte do úlohy na stejnou úroveň jako runs-on řádek environment: produkce a současně změňte podmínku sub v IAM na environmentovou hodnotu. Pokud další kroky potřebují obsah repozitáře, přidejte actions/checkout a oprávnění contents: read. Samotný krok ověřující identitu obsah repozitáře nepotřebuje.

Ověřte odmítnutí jiného repozitáře

Úspěšný běh ukáže, že povolená úloha roli převezme. Pro negativní test spusťte obdobné workflow ve vlastním odděleném testovacím repozitáři: ponechte id-token: write a stejný role-to-assume, ale nepřidávejte žádný nasazovací příkaz. Jeho sub se bude lišit identitou repozitáře, takže při přesné podmínce musí pokus o AssumeRoleWithWebIdentity skončit odmítnutím.

Pokud testovací repozitář roli přesto převezme, prohlédněte operátor a hodnotu sub v důvěryhodné zásadě. Vzor pokrývající všechny repozitáře organizace nebo všechny kontexty jednoho repozitáře může povolit více úloh, než nasazení potřebuje. Když naopak selže povolená úloha, porovnejte její skutečný formát sub s podmínkou, zkontrolujte audience, ARN poskytovatele a případné použití Environment. Negativní test provádějte s rolí omezenou na nezbytná oprávnění.

Deaktivujte a odstraňte staré klíče

Po úspěšném ověření identity i skutečného nasazení najděte původní AWS klíč v GitHub Secrets na úrovni repozitáře, Environment a případně organizace. Odstraňte odkazy na něj z workflow a zjistěte, zda jej nepoužívá další aplikace. Pokud ano, převeďte nejprve její přístup na vhodnou náhradu; změna jednoho workflow nesmí nečekaně přerušit ostatní procesy.

Postup AWS pro správu přístupových klíčů doporučuje před smazáním zkontrolovat poslední použití klíče, deaktivovat jej a ověřit fungování závislých aplikací. U příslušného uživatele IAM proto nejprve zkontrolujte údaj Last used, pak starý klíč deaktivujte a zopakujte běžné nasazení i další dotčené úlohy. Teprve po ověření odstraňte klíč z IAM a smažte jeho hodnoty z příslušných GitHub Secrets.

Přečtěte si také:

• GitHub přestal týdně skenovat spící repozitáře — ochranu lze vrátit měsíčně
• GitHub Actions, nebo GitLab CI: účet mění minuty, cache i runner
• AWS ukončí DevOps Guru, staré šablony mohou zablokovat nasazení