Oprávnění GITHUB_TOKEN: nejmenší oprávnění pro každé workflow

Každý job v GitHub Actions dostává token. GitHub na začátku každého jobu vytvoří nový GITHUB_TOKEN s rozsahem omezeným na repozitář, ve kterém workflow je, a může ho použít kterýkoli krok jobu. Co token smí, závisí na nastavení, na které se mnoho týmů nikdy nepodívalo, a ve starších repozitářích je odpovědí stále „zapisovat téměř všude“.

To je důležité ve chvíli, kdy se něco v jobu ukáže jako škodlivé. Při kompromitaci Nx „s1ngularity“ v srpnu 2025 měl token repozitáře stále oprávnění ke čtení i zápisu. Injekce ve workflow pull_request_target ho využila ke spuštění publikačního workflow, čímž unikl token npm použitý k publikování škodlivých verzí Nx. Token jen pro čtení by tento krok zastavil.

Tento článek vysvětluje, jak se oprávnění tokenu nastavují, co potřebují běžné úlohy a jak najít minimum pro vaše workflow.

Co je GITHUB_TOKEN

GITHUB_TOKEN je instalační přístupový token aplikace GitHub Actions. Několik vlastností se snadno přehlédne:

Existuje, ať ho používáte, nebo ne. Workflow na něj odkazují jako secrets.GITHUB_TOKEN, ale kterákoli action ho může přečíst přes kontext github.token, aniž by jí byl předán.
Ve výchozím stavu se zapisuje na disk. actions/checkout token uchová pro pozdější příkazy git, pokud nenastavíte persist-credentials: false. Před verzí v6 končil v .git/config; v6 ho přesunula do samostatného souboru v $RUNNER_TEMP. V roce 2024 zjistil výzkum ArtiPACKED od Unit 42, že tokeny unikaly přes artefakty, které obsahovaly .git/config.
Platnost končí s jobem. Na runnerech hostovaných na GitHubu to znamená nejvýše 6 hodin, tedy časový limit jobu. Na self-hosted runnerech ho lze obnovovat až 24 hodin.

Protože token je tam vždy, jediné, co máte pod kontrolou, je, kolik toho smí.

Výchozí nastavení: permissive, nebo restricted

Každý enterprise účet, organizace i repozitář má pro token výchozí nastavení:

Permissive: čtení a zápis u všech oprávnění.
Restricted: jen čtení u contents a packages, nic jiného.

Od 2. února 2023 mají nové enterprise účty, organizace a repozitáře výchozí nastavení restricted. Změna se nedotkla existujících, takže každý repozitář nebo organizace vytvořená dříve si ponechává výchozí permissive, pokud ho někdo nezměnil. Pokud vyšší úroveň zvolí restricted, nižší úrovně nemohou zvolit permissive.

Zkontrolujte to v Settings → Actions → General → Workflow permissions, nejprve na úrovni organizace. Ve stejné sekci je Allow GitHub Actions to create and approve pull requests, které by mělo zůstat vypnuté, pokud to workflow nepotřebuje.

Klíč permissions

Klíč permissions ve workflow upravuje token oproti výchozímu nastavení. Funguje na dvou úrovních:

permissions:
  contents: read

jobs:
  release:
    permissions:
      contents: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-commit-sha>

Pravidla:

Úroveň jobu přepisuje úroveň workflow. Nastavte výchozí hodnotu workflow jen pro čtení a oprávnění zvyšujte jen v jobech, které je potřebují.
Vše, co neuvedete, se stane none. Jakmile nastavíte jedno oprávnění, všechna ostatní se odeberou. permissions: {} odebere všechna.
Hodnoty jsou read, write nebo none. write zahrnuje read. read-all a write-all nastaví vše najednou; write-all se vyhněte.

Dostupná oprávnění k září 2026:

Oprávnění	Řídí
`actions`	Běhy workflow, artefakty a cache
`artifact-metadata`	Záznamy metadat artefaktů (v roce 2026 nahradilo `contents` pro tato API)
`attestations`	Atestace artefaktů
`checks`	Check runs a check suites
`code-quality`	Výsledky kvality kódu, například reporty pokrytí
`contents`	Obsah repozitáře, commity, větve, tagy a vydání
`deployments`	Nasazení
`discussions`	Diskuse
`id-token`	Vyžádání tokenu OIDC (jen `write` nebo `none`)
`issues`	Issues a komentáře
`packages`	GitHub Packages, včetně registru kontejnerů
`pages`	Buildy GitHub Pages
`pull-requests`	Pull requesty, labely a review
`security-events`	Výstrahy code scanningu a nahrávání SARIF
`statuses`	Stavy commitů
`vulnerability-alerts`	Výstrahy Dependabotu (jen `read` nebo `none`)

Když jobu chybí oprávnění, které potřebuje, volání API selže s chybou 403 Resource not accessible by integration. Tato chyba je signálem přidat jedno oprávnění, které krok potřebuje, ne přepnout na write-all.

Co potřebují běžné úlohy

Úloha	Oprávnění
Checkout kódu	`contents: read`
Vytvoření vydání nebo push tagu	`contents: write`
Komentář k issue nebo pull requestu	`issues: write` (komentáře k pull requestům jdou přes API pro issues)
Přidání labelů nebo review k pull requestu	`pull-requests: write`
Ověření vůči cloudovému poskytovateli přes OIDC	`id-token: write`
Vytvoření atestací artefaktů	`id-token: write`, `attestations: write`, `contents: read`, plus `packages: write` pro image kontejnerů
Push image do GitHub Container Registry	`packages: write`
Nahrání SARIF do code scanningu	`security-events: write`
Nasazení GitHub Pages z workflow	`pages: write`, `id-token: write`

Většina testovacích jobů a jobů buildu nepotřebuje nic kromě contents: read.

Forky, pull_request_target a Dependabot

Pull requesty z forků dostávají při události pull_request token jen pro čtení, ať workflow žádá cokoli, pokud administrátor nezapne „Send write tokens to workflows from pull requests“. Nechte to vypnuté.
pull_request_target dostává token pro čtení i zápis i u pull requestů z veřejných forků. Proto stojí za mnoha z nejznámějších krádeží tokenů: kompromitace Nx, kompromitace Ultralytics v prosinci 2024 i kompromitace action Trivy v březnu 2026 začaly workflow pull_request_target. GitHub ho zužuje: od července 2026 actions/checkout ve výchozím stavu odmítá v těchto workflow provést checkout kódu z forku a od 2. listopadu 2026 budou mít veřejné repozitáře bez vlastní politiky pull_request_target ve výchozím stavu vypnutý.
Pull requesty od Dependabotu se posuzují jako forky: token jen pro čtení a žádné secrets Actions. Pokud zvažujete jiné nástroje pro aktualizace, podívejte se na alternativy k Dependabotu.

Jak najít minimální oprávnění

Nemusíte to zjišťovat čtením zdrojového kódu každé action:

actions-permissions od GitHub Security Lab sleduje, jak workflow používá svůj token, a doporučí minimální oprávnění. Je ve veřejné betě.
Check Token-Permissions v OpenSSF Scorecard označuje workflow, která na nejvyšší úrovni nenastavují oprávnění jen pro čtení. Hodnotí ho jako vysoké riziko.
zizmor, statický analyzátor workflow, označuje nadměrná nebo výchozí oprávnění a checkouty, které uchovávají přístupové údaje.
Secure-Repo a Harden-Runner od StepSecurity doporučují oprávnění na úrovni jobů ze znalostní báze actions a z volání API, která job provádí.

Praktický postup zavedení: nastavte výchozí hodnotu organizace na restricted, na začátek každého workflow přidejte permissions: contents: read a workflow spusťte. Ta, která selžou s Resource not accessible by integration, vám přesně řeknou, který job potřebuje které další oprávnění.

Kam zapadá CRACI

Princip nejmenších oprávnění omezuje, co dokáže ukradený token. Nezabrání ale jeho krádeži a ostatní tajné údaje v jobu, například tokeny npm a cloudové přístupové údaje, jsou vystavené stejně.

CRACI spouští vaše joby GitHub Actions na vlastních runnerech. Změníte runs-on na craci; GITHUB_TOKEN, klíč permissions i nastavení repozitáře fungují jako dřív, protože token dál vydává GitHub. CRACI přidává to, co je na runneru: egress policy, která rozhoduje, ke kterým hostitelům se job smí připojit, validuje se před startem jobu a je fail-closed, a záznam každého balíčku, který job stáhl, se stopou jeho síťových spojení. Pokud se škodlivý kód v jobu přece jen zmocní tokenu, politika omezí, kam ho může poslat, a záznam ukáže, co se stalo.

Ke zbývajícím tajným údajům jobu si přečtěte Secrets v GitHub Actions: jak unikají a jak je zabezpečit. Rezervujte si demo a podívejte se na záznam jednoho z vašich vlastních buildů.