Подключение к частной сети

Сведения о средствах выполнения тестов, размещенных в GitHub

По умолчанию средства выполнения тестов, размещенные в GitHub, имеют доступ к общедоступному Интернету. Однако эти средства выполнения тестов также могут получить доступ к ресурсам в частной сети, например к реестру пакетов, диспетчеру секретов или другим локальным службам.

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

Использование шлюза API с OIDC

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

На следующей схеме представлен обзор архитектуры этого решения:

Важно проверить подлинность не только того, что маркер OIDC получен из GitHub Actions, но и то, что он получен конкретно от ожидаемых рабочих процессов, чтобы другие пользователи GitHub Actions не могли получить доступ к службам в частной сети. Для создания этих условий можно использовать утверждения OIDC. Дополнительные сведения см. в разделе Сведения об усилении защиты с помощью OpenID Connect.

Основным недостатком этого подхода является реализация шлюза API для выполнения запросов от вашего имени, а также его запуска на границе сети.

Но есть также и преимущества:

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

Дополнительные сведения см. в справочнике по реализации шлюза API (обратите внимание, что для этого требуется настройка вашего варианта использования и он не готов к запуску в режиме "как есть") и autoTITLE.

Создание наложения сети с помощью WireGuard

Если вы не хотите создавать отдельную инфраструктуру для шлюза API, можно создать сеть наложения между средством выполнения тестов и службой в частной сети, запустив WireGuard в обоих местах.

У этого подхода есть несколько недостатков.

• Чтобы подключиться к WireGuard, работающей в частной службе, потребуется известные IP-адрес и порт, на которые может ссылаться рабочий процесс: это может быть общедоступные IP-адрес и порт, сопоставление портов в сетевом шлюзе или служба, которая динамически обновляет DNS.
• В WireGuard отсутствует встроенная функция обработки обхода NAT, поэтому вам потребуется определить способ предоставления этой службы.
• Это подключение "один к одному", поэтому, если требуется высокий уровень доступности или высокая пропускная способность, необходимо создать это на основе WireGuard.
• Вам потребуется создать и безопасно хранить ключи для средства выполнения тестов и частной службы. WireGuard использует UDP, поэтому ваша сеть должна поддерживать трафик UDP.

Однако имеются и преимущества, например, вы можете запустить WireGuard на существующем сервере, поэтому вам не нужна отдельная инфраструктура, и она хорошо поддерживается средствами выполнения тестов, размещенными в GitHub.

Пример. Настройка WireGuard

В этом примере рабочий процесс настраивает WireGuard для подключения к частной службе.

В этом примере экземпляр WireGuard, запущенный в частной сети, имеет следующую конфигурацию:

• IP-адрес сети наложения 192.168.1.1
• Общедоступный IP-адрес и порт 1.2.3.4:56789
• Открытый ключ examplepubkey1234...

Экземпляр WireGuard в средстве выполнения тестов GitHub Actions имеет следующую конфигурацию:

• IP-адрес сети наложения 192.168.1.2
• Закрытые ключи хранятся в виде секретаGitHub Actions в WIREGUARD_PRIVATE_KEY

name: WireGuard example

on:
  workflow_dispatch:

jobs:
  wireguard_example:
    runs-on: ubuntu-latest
    steps:
      - run: sudo apt install wireguard

      - run: echo "$" > privatekey

      - run: sudo ip link add dev wg0 type wireguard

      - run: sudo ip address add dev wg0 192.168.1.2 peer 192.168.1.1

      - run: sudo wg set wg0 listen-port 48123 private-key privatekey peer examplepubkey1234... allowed-ips 0.0.0.0/0 endpoint 1.2.3.4:56789

      - run: sudo ip link set up dev wg0

      - run: curl -vvv http://192.168.1.1

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

Использование Tailscale для создания наложения сети

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

Его недостатки похожи на WireGuard: подключение "один к одному", поэтому может потребоваться дополнительная работа для обеспечения высокой доступности или высокой пропускной способности. Вам по-прежнему придется создавать ключи и безопасно хранить их. Протокол по-прежнему UDP, поэтому ваша сеть должна поддерживать трафик UDP.

Тем не менее, есть некоторые преимущества по сравнению с WireGuard: функция обхода NAT является встроенной, поэтому вам не нужно предоставлять порт для подключения к общедоступному Интернету. На сегодняшний день это самый быстрый из обсуждаемых вариантов, поскольку Tailscale предоставляет рабочий процесс GitHub Actions с одним шагом для подключения к сети наложения.

Дополнительные сведения см. в разделе Tailscale GitHub Action, а также в разделе Зашифрованные секреты о безопасном хранении ключей.