GITHUB_TOKEN: дефолтные права, least privilege и почему write-all — это footgun

Что это за токен и откуда его scope

Когда видишь supply-chain-инцидент в CI, первый вопрос всегда: что мог сделать скомпрометированный код? Ответ целиком определяется scope токена — поэтому стоит точно понять, откуда этот scope берётся, прежде чем писать первый блок permissions:.

В начале каждого job GitHub минтит свежий installation access token (токен доступа на уровне установки приложения) и отдаёт его как secrets.GITHUB_TOKEN (и github.token). Он привязан к текущему репо и истекает по окончании job — максимум на время прогона, никогда не сохраняется. Это хорошая новость. Плохая — его широта. У токена набор scope-прав — contents, pull-requests, issues, packages, actions, id-token и другие — каждый независимо read, write или none.

Откуда дефолтятся эти scope? Два слоя. Исторически репозитории создавались с пермиссивным дефолтом: токен получал read/write почти на все scope (contents: write, issues: write, pull-requests: write, …). Позже GitHub дал орг-ам переключить настройку орг/репо на ограниченный дефолт (contents: read, остальное none), и новые орги всё чаще стартуют с него — но полагаться на это нельзя. Единственный scope, что ты контролируешь наверняка, — тот, что пишешь сам:

permissions:
  contents: read          # склонировать репо, и не более

Объяви permissions: — и каждый неперечисленный scope падает в none. Этот единственный блок превращает ambient write-all токен в read-only независимо от дефолтной настройки репо.

# Top-level: применяется ко всем job как пол
permissions:
  contents: read

jobs:
  release:
    permissions:          # job-level: оверрайд только для этого job
      contents: write     # этот один job может запушить тег
      id-token: write     # и сминтить OIDC-токен (следующий урок)
    runs-on: ubuntu-latest
    steps: [...]

Least privilege, per job

Дисциплина двухчастна. Сначала задай ограничительный пол в начале воркфлоу — permissions: contents: read (или даже {} для нуля scope) — чтобы каждый job стартовал без того, что ему не нужно. Затем поднимай узко: только job, что публикует релиз, получает contents: write; только job, что комментирует PR, получает pull-requests: write; только job, что аутентифицируется в облако, получает id-token: write. Job-level блок permissions: полностью заменяет унаследованный набор для этого job — он не аддитивен, так что перечисление одного scope роняет все остальные в none.

Это важно из-за того, как токен достаёт код. Каждый шаг в job — каждый сторонний Action, каждый run:-скрипт, каждая транзитивная npm- или pip-зависимость, что они выполняют — работает с тем же токеном job, доступным в окружении и для GitHub API. Per-step-песочницы токена нет. Так что scope токена — это объединение доверия, что ты распространяешь на каждую строку кода в этом job. Пиннинг Action-ов к полному commit SHA (uses: owner/action@<40-символьный-sha>) закрывает половину какой код запускается; least-privilege permissions: закрывает половину что этот код может. Нужны обе: пиннинг без скоупинга всё ещё выдаёт write-all токен запиненному-но-позже-скомпрометированному коду, а скоупинг без пиннинга всё ещё гоняет произвольный изменяемый код, лишь с меньшим охватом.