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

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

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

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

Преимущества пересылки агента SSH

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

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

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

Настройка пересылки агента SSH

Включите перенаправление агента локально. Дополнительные сведения см. в нашем руководстве по перенаправлению агента SSH.
Задайте сценарии развертывания для перенаправления агента. Например, в сценарии 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 подключает общедоступную часть ключа непосредственно к репозиторию вместо личная учетная запись, а частная часть ключа остается на сервере. Дополнительные сведения см. в разделе Доставка развертываний.

Развертывание ключей с доступом на запись может запускать те же действия, что и член организации с правами администратора или участник совместной работы в личном репозитории. Дополнительные сведения см. в разделе [AUTOTITLE и Роли репозиториев для организации](/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/permission-levels-for-a-personal-account-repository).

Для повышения безопасности и тонкого контроля доступа к репозиторию и разрешений мы рекомендуем использовать приложение GitHub. См . раздел AUTOTITLE.

Преимущества ключ развертывания

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

Минусы ключ развертывания

Ключи развертывания предоставляет доступ только к одному репозиторию. Более сложные проекты могут содержать множество репозиториев для извлечения на тот же сервер.
Ключи развертывания, как правило, не защищены парольной фразой, что упрощает доступ к ключу, если сервер скомпрометирован.
Развертывание ключей — это учетные данные, которые не имеют даты окончания срока действия.
Ключи развертывания не связаны непосредственно с членством в организации. Если пользователь, создавший ключ развертывания, удаляется из репозитория, ключ развертывания по-прежнему будет активным, так как он не привязан к конкретному пользователю, а не к репозиторию.

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

Примечание.

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

Запустите ssh-keygenпроцедуру на сервере и запомните путь сохранения созданной пары ключей открытого и закрытого ключей RSA.
На GitHubперейдите на главную страницу репозитория.
Под именем репозитория щелкните Settings. Если вкладка "Параметры" не отображается, выберите раскрывающееся меню и нажмите кнопку "Параметры".
На боковой панели нажмите кнопку "Развернуть ключи".
Нажмите кнопку "Добавить ключ развертывания".
В поле "Заголовок" укажите заголовок.
В поле "Ключ" вставьте открытый ключ.
Выберите Разрешить доступ на запись, если этот ключ должен иметь доступ на запись в репозитории. Ключ развертывания с доступом на запись позволяет отправить развертывание в репозиторий.
Нажмите Добавить ключ.

Для создания ключ развертывания также можно использовать REST API. Дополнительные сведения см. в разделе Конечные точки REST API для ключ развертывания.

Затем вы можете взаимодействовать с репозиторием через SSH. Например:

git clone [email protected]:OWNER/REPO.git

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

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

В файле конфигурации сервера 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 [email protected]:OWNER/repo-1.git

GitHub App Токены доступа для установки

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

Поскольку GitHub Apps они являются актёром первого класса на GitHub, токены доступа установки отделены от любого GitHub пользователя, что делает их сопоставимыми с «сервисными токенами». Кроме того, маркеры доступа к установке имеют специальные ограничения скорости, которые масштабируются с размером организаций, над которыми они действуют. Для получения дополнительной информации см. раздел Лимиты ставок для GitHub Apps.

Преимущества маркеров доступа к установке

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

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

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

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

Определите, стоит ли вам GitHub App быть публичным или частным. Если вы GitHub App будете действовать только на репозиториях внутри вашей организации, скорее всего, вы хотите сделать это приватным.
Определите, какие права GitHub App вам нужны, например, доступ только для чтения к содержимому репозитория.
Создайте GitHub App страницу настроек вашей организации. Для получения дополнительной информации см. Создание GitHub App.
Обратите внимание на своё GitHub Appid.
Сгенерируйте и скачайте свой GitHub Appприватный ключ и храните его в безопасности. Дополнительные сведения см. в статье Создание закрытого ключа.
Установите GitHub App свои репозитории на нужные репозитории, по желанию вы можете установить GitHub App их на все репозитории вашей организации.
Определите то, installation_id что отражает связь между вашим GitHub App и репозиториями организации, к которым оно имеет доступ. Каждая GitHub App пара организации имеет не более одного installation_id. Можно определить этот installation_id с помощью получения установки организации для приложения, прошедшего проверку подлинности. Для этого требуется аутентификация с GitHub App помощью JWT, для получения дополнительной информации см . раздел «Аутентификация как GitHub App.
Создайте маркер доступа к установке с помощью соответствующей конечной точки REST API, создайте маркер доступа установки для приложения. Для этого требуется аутентификация с GitHub App помощью JWT, для получения дополнительной информации см. Аутентификация как GitHub Appa и Аутентификация как установка.
Используйте этот маркер доступа к установке для взаимодействия с репозиториями через ИНТЕРФЕЙСы REST или GraphQL API или через клиент Git.

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

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

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

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

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

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

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

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

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