write permissions
Тема дорожной карты · GitHub Actions
Права на запись в GITHUB_TOKEN — это области, такие как contents: write, packages: write, pull-requests: write или id-token: write, позволяющие заданию GitHub Actions изменять репозиторий или создавать OIDC-токены. В отличие от более безопасных значений read по умолчанию, права на запись предоставляются точечно через ключ permissions: на уровне workflow или задания. Это позволяет заданию делать push коммита, публиковать пакет или принять облачную роль, оставляя остальные шаги runner'а в режиме только чтения. Комбинирование минимальных прав на запись с правилами защиты окружений и требованием ревьюеров — рекомендуемый паттерн hardening, особенно для workflow, запускаемых по pull_request из форков. Аудит каждого права на запись в CI/CD-workflow — высокоэффективный способ снизить радиус поражения при компрометации action или runner'а.
Права на запись играют ключевую роль в обеспечении безопасности и контроля доступа для GitHub Actions. Они позволяют заданиям автоматически выполнять необходимые операции, такие как публикация кода или пакетов, без необходимости ввода дополнительных учетных записей или ключей. Однако, предоставление этих прав требует осторожности, чтобы избежать утечек или нежелательных действий.
Как это работает
write permissions: permissions:-блок ограничивает scope автопровиженного GITHUB_TOKEN. На workflow-уровне или per-job. Дефолт — permissions: write-all для многих старых репо; современная практика — permissions: contents: read на workflow-уровне + эскалация per-job (pull-requests: write для постинга PR-комментов, packages: write для push образов). OIDC-токен (id-token: write) для cloud-auth.
Когда применять
Всегда least privilege — начните с permissions: contents: read сверху, write только где надо per-job. Для OIDC (cloud-auth без long-lived ключей) — id-token: write только на deploy-job. Аудитьте workflows через pinact или похожие тулы для нахождения отсутствующих пинов + широких прав.
Права на запись следует применять только в тех случаях, когда это действительно необходимо для выполнения определенных задач. Например, если задание должно публиковать новый код или обновить пакет, то для этого задания должны быть предоставлены соответствующие права на запись. Важно помнить, что предоставление этих прав увеличивает риск эксплуатации, поэтому необходимо тщательно контролировать и аудировать их использование.
Типичные ошибки
Ловушки write permissions: оставлен дефолтный permissions: write-all (каждый шаг может push commits, комментить PR, менять settings — security-риск); over-grant на workflow-уровне "чтобы работало" вместо per-job (теряет least privilege); непонимание разницы между GITHUB_TOKEN и PAT (разные scopes, разные lifetime).
Типичные ошибки при использовании прав на запись включают предоставление слишком широких прав на уровне workflow, что увеличивает риск эксплуатации. Также часто встречается ситуация, когда права на запись остаются по умолчанию (permissions: write-all), что позволяет каждому шагу в задании выполнять операции записи, такие как публикация коммитов или изменения настроек репозитория. Это представляет собой значительный риск для безопасности, поскольку каждый шаг теперь может выполнять операции записи без необходимости дополнительной проверки.