Skip to main content
Мы публикуем частые обновления нашей документации, и перевод этой страницы может все еще выполняться. Актуальные сведения см. в документации на английском языке.
All products
Аутентификация

Управление ключами развертывания

В этой статье

Изучите несколько способов управлять ключами SSH на серверах при автоматизации сценариев развертывания и узнайте, какой из них вам лучше подходит.

Ключами SSH можно управлять на серверах при автоматизации сценариев развертывания с помощью перенаправления агента SSH, HTTPS с токенами OAuth, развертывания ключей или пользователей компьютера.

Перенаправление агента SSH

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

Плюсы переадресации агента SSH

  • Создавать или отслеживать новые ключи не нужно.
  • Управление ключами отсутствует; пользователи имеют те же разрешения на сервере, что и на локальном компьютере.
  • Ключи не хранятся на сервере, поэтому, если сервер скомпрометирован, вам не нужно искать и удалять скомпрометированные ключи.

Недостатки переадресации агента SSH

  • Пользователи должны выполнять развертывание по протоколу SSH; Невозможно использовать автоматизированные процессы развертывания.
  • Перенаправление агента SSH может быть сложной задачей для пользователей Windows.

Настройка переадресации агента SSH

  1. Включите перенаправление агента локально. Дополнительные сведения см. в нашем руководстве по перенаправлению агента SSH.
  2. Задайте сценарии развертывания для перенаправления агента. Например, в сценарии bash включение перенаправления агента будет выглядеть примерно так: ssh -A serverA 'bash -s' < deploy.sh

Клонирование HTTPS с помощью токенов OAuth

Если не требуется использовать ключи SSH, можно использовать HTTPS с токенами OAuth.

Плюсы клонирования HTTPS с помощью маркеров OAuth

  • Любой пользователь с доступом к серверу может развернуть репозиторий.

  • Пользователям не нужно изменять локальные параметры SSH.

  • Несколько токенов (по одному для каждого пользователя) не требуется; достаточно одного токена на сервер.

  • Токен можно отозвать в любое время, превратив его в одноразовый пароль.

  • Новые токены можно легко создать с помощью сценария API OAuth.

Минусы клонирования HTTPS с помощью маркеров OAuth

  • Необходимо убедиться, что токен настроен с правильными областями доступа.
  • По сути токены являются паролями и должны защищаться так же.

Настройка клонирования HTTPS с помощью маркеров OAuth

Ознакомьтесь с нашим руководством по созданию personal access token.

Ключи развертывания

Вы можете запускать проекты из репозитория на экземпляр GitHub Enterprise Server на сервере с помощью ключа развертывания, который представляет собой ключ SSH, который предоставляет доступ к одному репозиторию. GitHub Enterprise Server присоединяет открытую часть ключа непосредственно к репозиторию, а не к личной учетной записи. Закрытая часть ключа при этом остается на сервере. Дополнительные сведения см. в разделе Доставка развертываний.

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

Профи развертывания ключей

  • Любой пользователь с доступом к репозиторию и серверу может развернуть проект.
  • Пользователям не нужно изменять локальные параметры SSH.
  • Ключи развертывания по умолчанию доступны только для чтения, но вы можете предоставить им доступ для записи при добавлении их в репозиторий.

Недостатки ключей развертывания

  • Ключи развертывания предоставляет доступ только к одному репозиторию. Более сложные проекты могут содержать множество репозиториев для извлечения на тот же сервер.
  • Ключи развертывания, как правило, не защищены парольной фразой, что упрощает доступ к ключу, если сервер скомпрометирован.

Настройка ключей развертывания

  1. Запустите ssh-keygenпроцедуру на сервере и запомните путь сохранения созданной пары ключей открытого и закрытого ключей RSA.

  2. На экземпляр GitHub Enterprise Server перейдите на главную страницу репозитория. 1. Под именем репозитория щелкните Параметры. Если вкладка "Параметры" не отображается, выберите раскрывающееся меню и нажмите кнопку Параметры.

    Снимок экрана: заголовок репозитория с вкладками. Вкладка "Параметры" выделена темно-оранжевым контуром.

  3. На боковой панели щелкните Развернуть ключи.

  4. Щелкните Добавить ключ развертывания.

  5. В поле "Заголовок" укажите заголовок.

  6. В поле Key (Ключ) вставьте открытый ключ.

  7. Выберите Разрешить доступ на запись, если этот ключ должен иметь доступ на запись в репозитории. Ключ развертывания с доступом на запись позволяет отправить развертывание в репозиторий.

  8. Нажмите Добавить ключ.

Использование нескольких репозиториев на одном сервере

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

В файле конфигурации сервера SSH (обычно ~/.ssh/config) добавьте запись псевдонима для каждого репозитория. Пример:

Host my-GHE-hostname.com-repo-0
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host my-GHE-hostname.com-repo-1
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key
  • Host my-GHE-hostname.com-repo-0 — псевдоним репозитория.
  • Hostname my-GHE-hostname.com — настраивает имя узла для использования с псевдонимом.
  • IdentityFile=/home/user/.ssh/repo-0_deploy_key — назначает псевдониму закрытый ключ.

Затем можно использовать псевдоним имени узла для взаимодействия с репозиторием с помощью SSH, который будет использовать уникальный ключ развертывания, назначенный данному псевдониму. Пример:

$ git clone git@my-GHE-hostname.com-repo-1:OWNER/repo-1.git

Маркеры доступа установки GitHub App

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

Так как приложения GitHub являются субъектом первого класса в GitHub Enterprise Server, маркеры доступа установки отделяются от любого пользователя GitHub, что делает их сопоставимыми с "маркерами службы". Кроме того, маркеры доступа к установке имеют специальные ограничения скорости, которые масштабируются в зависимости от размера организаций, с которыми они действуют. Дополнительные сведения см. в разделе Ограничения скорости для GitHub Apps.

Плюсы установки маркеров доступа

  • Строго ограниченные маркеры с четко определенными наборами разрешений и сроком действия (1 час или меньше, если отозван вручную с помощью API).
  • Выделенные ограничения скорости растут вместе с вашей организацией.
  • Отсоединено от удостоверений пользователей GitHub, поэтому лицензированные места не используются.
  • Пароль никогда не предоставлялся, поэтому невозможно выполнить прямой вход в систему.

Недостатки маркеров доступа для установки

  • Для создания приложения GitHub требуется дополнительная настройка.
  • Срок действия маркеров доступа для установки истекает через 1 час, поэтому их необходимо создать повторно, обычно по запросу с помощью кода.

Настройка маркеров доступа для установки

  1. Определите, каким должно быть приложение GitHub: общедоступным или частным. Если ваше приложение GitHub будет работать в вашей организации только с репозиториями, вероятно, вы захотите, чтобы оно было частным.
  2. Определите разрешения, требуемые для приложения GitHub, например, доступ только для чтения к содержимому репозитория.
  3. Создайте приложение GitHub с помощью страницы параметров организации. Дополнительные сведения см. в разделе Создание приложения GitHub.
  4. Запишите id своего приложения GitHub.
  5. Создайте и скачайте закрытый ключ приложения GitHub и сохраните его в надежном месте. Дополнительные сведения см. в статье Создание закрытого ключа.
  6. Установите приложение GitHub в репозиториях, в которых оно должно работать. При необходимости можно установить приложение GitHub на все репозитории в вашей организации.
  7. Определите installation_id, который представляет собой подключение между приложением GitHub и репозиториями организации, к которым можно получить доступ. Каждая пара «приложение GitHub и организация» имеет не более одного installation_id. Можно определить этот installation_id с помощью получения установки организации для приложения, прошедшего проверку подлинности. Для этого требуется проверка подлинности в приложении GitHub с помощью JWT. Дополнительные сведения см. в статье Проверка подлинности в приложении GitHub.
  8. Создайте маркер доступа установки с помощью соответствующей конечной точки REST API . Создание маркера доступа установки для приложения. Для этого требуется проверка подлинности в приложении GitHub с помощью JWT. Дополнительные сведения см. в статье Проверка подлинности в приложении GitHub и Проверка подлинности при установке.
  9. Используйте этот маркер доступа для установки для взаимодействия с репозиториями через ИНТЕРФЕЙСы REST, API GraphQL или клиент Git.

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

Пользователи компьютеров

Если серверу требуется доступ к нескольким репозиториям, можно создать новую учетную запись в экземпляр GitHub Enterprise Server и подключить ключ SSH, который будет использоваться исключительно для автоматизации. Так как эта учетная запись в экземпляр GitHub Enterprise Server не будет использоваться человеком, она называется пользователем компьютера. Вы можете добавить пользователя компьютера в качестве участника совместной работы в личном репозитории (предоставление права на чтение и запись), в качестве внешнего участника совместной работы в репозитории организации (предоставление права на чтение, записи или администратора) или для команды с доступом к репозиториям, которые необходимо автоматизировать (предоставление прав команде).

Профи пользователей компьютеров

  • Любой пользователь с доступом к репозиторию и серверу может развернуть проект.
  • Пользователям не нужно изменять их локальные параметры SSH.
  • Несколько ключей не требуются; одного на сервер достаточно.

Минусы пользователей компьютеров

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

Настройка пользователей компьютера

  1. Запустите ssh-keygenпроцедуру на сервере и подключите открытый ключ к учетной записи пользователя компьютера.
  2. Предоставьте учетной записи пользователя компьютера доступ к репозиториям, которые требуется автоматизировать. Это можно сделать, добавив учетную запись в качестве участника совместной работы, в качестве внешнего участника совместной работы или для команды в организации.

Дополнительные материалы