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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

В файле конфигурации сервера 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

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

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

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

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

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

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

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

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

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

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

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