Применение политик для GitHub Actions в вашем предприятии

Для GitHub Actionsчего нужны полисы?

Корпоративные политики контролируют опции, доступные членам предприятия при использовании GitHub Actions.

Если вы не применяете корпоративные политики, владельцы организаций и пользователи с разрешением «Управление действиями организации» имеют полный контроль над GitHub Actions своими организациями.

Применение политик

1. Перейдите к своему предприятию. Например, на странице Enterprises на GitHub.com.
2. В верхней части страницы нажмите «Политики».
3. В разделе " Policies", нажмите кнопку "Действия".
4. После настройки каждой политики нажмите кнопку "Сохранить".

Дополнительные сведения о каждом разделе страницы "Политики" см. в разделе "Политики".

Политики

В разделе «Политики» вы можете контролировать, какие организации внутри вашего предприятия могут использовать GitHub Actions, с помощью следующих опций:

• Enable GitHub Actions для всех организаций
• Поддержка GitHub Actions для конкретных организаций
• Отключён GitHub Actions для всех организаций

Контроль доступа к публичным действиям и повторно используемым рабочим процессам

Предприятия часто хотят ограничить доступ только к хорошо проверенной группе публичных действий и повторно используемых рабочих процессов в рамках управления цепочкой поставок. Политики, доступные в , GitHub позволяют управлять доступом без блокировки динамических рабочих процессов, используемых code scanning и GitHub Code Quality.

Вы можете применять строгие контроли без определения исключений или дополнительной конфигурации для code scanning и GitHub Code Quality, с помощью следующих опций:

• Разрешить все действия и повторно используемые рабочие процессы: можно использовать любое действие или повторно используемый рабочий процесс, независимо от того, кто их создал и где он определен.
• Разрешить корпоративные действия и повторно используемые рабочие процессы: Можно использовать только действия и повторно используемые рабочие процессы , определённые в репозитории внутри предприятия. Блокирует доступ к действиям, созданным GitHub, таким как actions/checkout действие.
• **Разрешить предприятиям и выбрать не корпоративные, действия и повторно используемые рабочие процессы: Любое действие или повторно используемый рабочий процесс , определённый в репозитории внутри предприятия, может использоваться, а также любой действие или повторно используемый рабочий процесс , соответствующий указанным вами критериям.
• Требовать, чтобы действия были закреплены на полной длине фиксации SHA: все действия должны быть закреплены на полной длине фиксации SHA для использования. Это включает действия вашего бизнеса и действия, GitHubсозданные . Повторно используемые рабочие процессы всё ещё можно сталкиваться по тегу. Дополнительные сведения см. в разделе Справочник по безопасному использованию.

**Разрешить предприятиям и выбрать не корпоративные, действия и повторно используемые рабочие процессы

Если вы выберете эту опцию, разрешены действия и повторно используемые рабочие процессы внутри вашего предприятия, а также у вас будут следующие опции для разрешения других действий и повторно используемых рабочих процессов:

• Разрешить действия, созданные : GitHub Разрешает все действия, созданные GitHub, расположенные actions в и github организациях.
• Разрешить действия Marketplace проверенным создателям: Разрешает все GitHub Marketplace действия, созданные проверенными создателями, помеченными .
• Разрешать или блокировать указанные действия и повторно используемые рабочие процессы: разрешает действия и повторно используемые рабочие процессы, которые вы задаёте. Вы можете указывать отдельные действия и повторно используемые рабочие процессы или целые организации и репозитории.

При указании действий и повторно используемых рабочих процессов используйте следующий синтаксис:

• Чтобы ограничить доступ к определённым тегам или закрепить SHA действия или повторно используемого рабочего процесса, используйте тот же синтаксис, что и в этом рабочем процессе, для выбора действия или повторно используемого рабочего процесса.
  • Для действия используется синтаксис OWNER/REPOSITORY@TAG-OR-SHA. Например, используйте actions/javascript-action@v1.0.1, чтобы выбрать тег или actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f для выбора SHA.
  • Для многократно используемого рабочего процесса используется синтаксис OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA. Например: octo-org/another-repo/.github/workflows/workflow.yml@v1.
• Чтобы указать шаблон, используйте подстановочный знак. *
  • Чтобы разрешить все действия и повторно используемые рабочие процессы в организациях, начинающихся с space-org, используйте space-org*/*.
  • Чтобы разрешить все действия и повторно используемые рабочие процессы в репозиториях, начинающихся с octocat, используйте */octocat**@*.
• Чтобы указать несколько шаблонов, используйте , для разделения шаблонов.
  • Чтобы разрешить все действия и повторно используемые рабочие процессы от octocat организаций octokit , используйте octocat/*, octokit/*.
• Чтобы заблокировать определенные шаблоны, используйте ! префикс.
  • Чтобы разрешить все действия и повторно используемые рабочие процессы организации space-org , но заблокировать конкретное действие, например space-org/action, использовать space-org/*, !space-org/action@*.
  • По умолчанию разрешены только действия и повторно используемые рабочие процессы, указанные в списке. Чтобы разрешить все действия и повторно используемые рабочие процессы, одновременно блокируя конкретные действия, используйте *, !space-org/action@*.

Политики никогда не ограничивают доступ к локальным действиям в файловой системе runner (где uses: начинается ./путь).

Средства выполнения

По умолчанию любой пользователь с доступом администратора к репозиторию может добавить локального runner для репозитория, а локальные runners могут столкнуться с рисками:

• Нет никакой гарантии, что локальные модули запуска будут размещаться на временных виртуальных машинах. В результате они могут быть скомпрометированы ненадежным кодом в рабочем процессе.
• Любой пользователь, который может вилировать репозиторий и открыть запрос на вытягивание, может компрометировать локальную среду выполнения, потенциально получая доступ к секретам и GITHUB_TOKENдоступу на запись в репозиторий.

В разделе "Runners" вы можете медиатировать эти риски, отключив использование локальных средств выполнения на уровне репозитория.

• Отключить для всех организаций: запрещает создание средств выполнения на уровне репозитория.
• Отключить во всех репозиториях управляемых пользователей предприятия (EMU): Предотвращает создание раннеров для репозиториев, принадлежащих управляемые учетные записи пользователей.

Отключение стандартных ведущих бегунов

Вы можете отключить стандартные GitHub-hosted runners на корпоративном уровне. Эта настройка требует рабочих процессов для таргетирования раннеров через группы раннеров и помогает обеспечивать единый контроль доступа и управление.

Для информации о ограничениях по параллельности профессий для GitHub-hosted runners см. Ограничения действий.

1. Перейдите к своему предприятию. Например, на странице Enterprises на GitHub.com.
2. В верхней части страницы нажмите «Политики».
3. В разделе " Policies", нажмите кнопку "Действия".
4. Прокрутите до раздела «Стандартные размещённые бегуны» и нажмите «Отключить для всех организаций».
5. Нажмите кнопку Сохранить.

Пользовательские образы

В разделе "Пользовательские образы" вы можете контролировать, каким организациям в вашем предприятии разрешено создавать пользовательские образы и управлять ими с помощью следующей политики доступа:

• Включить для всех организаций: все организации, включая те, которые будут созданы в будущем, могут использовать или создавать пользовательские образы.
• Включить для определенных организаций: только выбранные организации могут использовать или создавать пользовательские образы.
• Отключить для всех организаций: ни одна организация не может использовать или создавать пользовательские изображения.

Политики хранения пользовательских образов

Можно указать, как долго будут храниться версии пользовательских образов и когда они станут неактивными.

• Максимальное количество версий на изображение: ограничивает количество сохраняемых версий каждого образа. При превышении этого лимита самые старые неиспользуемые версии образа автоматически удаляются.
  • По умолчанию: 20 версий
  • Конфигурируемый диапазон: от 1 до 100 версий
• Хранение неиспользуемых версий: удаляет версии образов, которые не использовались в течение указанного количества дней. Версии образов, назначенные пулу средств выполнения, но не используемые активно, также считаются неиспользуемыми.
  • По умолчанию: 30 дней
  • Настраиваемый диапазон: от 1 до 90 дней
• Maximum version age: Отключает версии образов, которые были созданы ранее указанного количества дней. Отключенные версии образов не могут использоваться средствами выполнения тестов до тех пор, пока ограничение политики не будет увеличено.
  • По умолчанию: 60 дней
  • Настраиваемый диапазон: 7–90 дней

артефактов, логов и кэша Сохранение артефактов и логов

По умолчанию артефакты и файлы журналов, созданные рабочими процессами, хранятся в течение 90 дней. Вы можете изменить период удержания.

• Для общедоступных репозиториев можно настроить период от 1 до 90 дней.
• Для частных и внутренних репозиториев можно настроить период от 1 до 400 дней.

Изменения применяются только к новым артефактам и файлам журналов.

Параметры кэша

Вы можете настроить максимальное удержание кэша и ограничения по размеру, которые будут действовать на всём вашем предприятии. Если вы увеличите лимит выселения «размера кэша» сверх 10 ГБ, предусмотренный вашим тарифом, вам будет взиматься плата за дополнительное хранение кэшированных записей.

По умолчанию:

• Кэши сохраняются в течение 7 дней перед автоматическим удалением.
• Общий лимит кэша — 10 ГБ на репозиторий.

Вы можете настроить эти параметры, чтобы установить максимальные лимиты для хранения кэша и размера кэша по всему вашему предприятию:

• Сохранение кэша: настройте до 90 дней для публичных репозиториев или до 365 дней для приватных и внутренних репозиториев.
• Лимит выселения размера кэша: Настройте до 10 000 ГБ на репозиторий.

Настройки, которые вы настраиваете на корпоративном уровне, служат максимальными пределами. Владельцы организаций могут самостоятельно настроить лимиты для своей организации, но не могут превышать установленные на уровне предприятия. Администраторы репозиториев могут самостоятельно настраивать ограничения для своих репозиториев, но не могут превышать установленные на уровне организации.

Для получения дополнительной информации о выселении кэша см. Справочник по кэшированию зависимостей.

Рабочие процессы запроса на вытягивание из внешний участник совместной работы

Любой пользователь может закрепить общедоступный репозиторий, а затем отправить запрос на вытягивание, чтобы предложить изменения рабочих процессов репозитория. Чтобы предотвратить злоупотребление, рабочие процессы не будут выполняться автоматически при запросах на вытягивание, созданных некоторыми участниками.

Вы можете настроить запросы на вытягивание, требующие утверждения, прежде чем они будут запущены.

• Требовать одобрения для новых участников, которые являются новичкими GitHub. Требуется одобрение пользователей, которые никогда не подписывались на репозиторий и имеют новые GitHub аккаунты.
• Требовать утверждения для участников первого раза. Требуется утверждение для пользователей, которые никогда не выполняли фиксацию в репозитории.
• Требовать утверждения для всех внешний участник совместной работы. Требуется утверждение для всех пользователей, которые не являются членами организации.

Рабочие процессы запроса на вытягивание в частных репозиториях

Вы можете управлять тем, как пользователи могут запускать рабочие процессы в pull_request событиях в частных и внутренних репозиториях.

• Выполнение рабочих процессов из запросов на вытягивание вилки. Пользователи могут запускать рабочие процессы из запросов на вытягивание вилки. По умолчанию рабочие процессы будут использовать GITHUB_TOKEN разрешение только для чтения, без доступа к секретам.
• Отправка маркеров записи в рабочие процессы из запросов на вытягивание. Рабочие процессы будут использовать GITHUB_TOKEN разрешение на запись.
• Отправка секретов в рабочие процессы из запросов на вытягивание. Все секреты доступны для запроса на вытягивание.
• Требовать утверждения для рабочих процессов запроса на вытягивание вилки. Рабочие процессы по запросу на вытягивание от сотрудников без разрешения на запись потребуют утверждения от кого-либо с разрешением на запись перед их выполнением.

Если политика включена на уровне предприятия, ее можно выборочно отключить в отдельных организациях или репозиториях. Если политика отключена на уровне предприятия, отдельные организации или репозитории не могут включить ее.

Разрешения рабочего процесса

В разделе "Разрешения рабочего процесса" можно задать разрешения по умолчанию , предоставленные параметру GITHUB_TOKEN.

• Разрешения на чтение и запись: разрешения по умолчанию зависят GITHUB_TOKEN от того, когда была создана организация или организация:

  • Создано или после 2 февраля 2023 г. — по умолчанию используется доступ только для чтения для всех областей.
  • Создано до 2 февраля 2023 г. — по умолчанию используется доступ для чтения и записи для всех областей.

• Разрешения на чтение содержимого и пакетов репозитория: по умолчанию GITHUB_TOKEN имеет только доступ на чтение для contents областей и packages областей. Более разрешительный параметр нельзя выбрать в качестве значения по умолчанию для отдельных организаций или репозиториев.

Любой пользователь с доступом на запись в репозиторий по-прежнему может изменить разрешения, предоставленные GITHUB_TOKEN конкретному рабочему процессу, изменив permissions ключ в файле рабочего процесса.

Разрешить GitHub Actions создавать и одобрять pull request по умолчанию отключен. Если этот параметр включен, GITHUB_TOKEN можно создать и утвердить запросы на вытягивание.