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

Ключами 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.
• Несколько токенов (по одному для каждого пользователя) не требуется; достаточно одного токена на сервер.
• Токен можно отозвать в любое время, превратив его в одноразовый пароль.

Недостатки клонирования HTTPS с маркерами OAuth

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

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

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

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

Вы можете запустить проекты из репозитория на GitHub.com на сервер с помощью ключ развертывания, который является ключом 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. См. раздел "Выбор момента создания приложения GitHub".

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

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

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

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

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

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

2. На GitHubперейдите на главную страницу репозитория.

3. Под именем репозитория щелкните Параметры. Если вкладка "Параметры" не отображается, выберите раскрывающееся меню и щелкните Параметры.

   

4. На боковой панели нажмите кнопку "Развернуть ключи".

5. Нажмите кнопку "Добавить ключ развертывания".

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

7. В поле "Ключ" вставьте открытый ключ.

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

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

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

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

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

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

Host github.com-repo-0
        Hostname github.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host github.com-repo-1
        Hostname github.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key

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

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

git clone git@github.com-repo-1:OWNER/repo-1.git

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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