Однако эти средства выполнения тестов также могут получить доступ к ресурсам в частной сети, например к реестру пакетов, диспетчеру секретов или другим локальным службам.
Средства выполнения тестов, размещенные в GitHub, используются совместно всеми клиентами GitHub, поэтому вам потребуется способ подключения частной сети только к вашим средствам выполнения сети во время выполнения ими рабочих процессов.
Существует несколько различных подходов, которые можно использовать для настройки этого доступа, каждый из которых имеет различные преимущества и недостатки.
Использование шлюза API с OIDC С помощью GitHub Actions можно использовать маркеры OpenID Connect (OIDC) для проверки подлинности рабочего процесса за пределами GitHub Actions.
Например, можно запустить шлюз API на границе частной сети, который проверяет подлинность входящих запросов с помощью маркера OIDC, а затем отправляет запросы API от имени рабочего процесса в частную сеть.
На следующей схеме представлен обзор архитектуры этого решения:
Схема архитектуры шлюза OIDC, начиная с средства выполнения GitHub Actions и заканчивая частной службой частной сети. Важно проверить подлинность не только того, что маркер OIDC получен из GitHub Actions, но и то, что он получен конкретно от ожидаемых рабочих процессов, чтобы другие пользователи GitHub Actions не могли получить доступ к службам в частной сети.
Для создания этих условий можно использовать утверждения OIDC.
.](/assets/cb-22109/mw-1000/images/help/images/actions-oidc-gateway.webp)
Основным недостатком этого подхода является реализация шлюза 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
Дополнительные сведения см. в разделе Краткое руководство по WireGuard, а также в разделе "Зашифрованные секреты", чтобы узнать, как безопасно хранить ключи.
- Использование Tailscale для создания наложения сети
- Tailscale — это коммерческий продукт на базе WireGuard.
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, за исключением того, что Tailscale является более полноценным продуктом, а не компонентом с открытым кодом.
Его недостатки аналогичны WireGuard: подключение "один к одному", поэтому может потребоваться дополнительная работа для обеспечения высокой доступности или высокой пропускной способности.
Вам по-прежнему придется создавать ключи и безопасно хранить их. Протокол по-прежнему UDP, поэтому ваша сеть должна поддерживать трафик UDP.
Тем не менее, есть некоторые преимущества по сравнению с WireGuard: функция обхода NAT является встроенной, поэтому вам не нужно предоставлять порт для подключения к общедоступному Интернету. На сегодняшний день это самый быстрый из обсуждаемых вариантов, поскольку Tailscale предоставляет рабочий процесс GitHub Actions с одним шагом для подключения к сети наложения. Дополнительные сведения о безопасном хранении ключей см. в разделе Tailscale GitHub Action, а также в разделе Зашифрованные секреты.
However, there are some advantages over WireGuard: NAT traversal is built-in, so you don't need to expose a port to the public internet. It is by far the quickest of these options to get up and running, since Tailscale provides an GitHub Actions workflow with a single step to connect to the overlay network.
For more information, see the