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