Прокси в GitHub Actions: хранение секретов и безопасная настройка CI/CD

Когда рабочему процессу требуется доступ к внутреннему репозиторию пакетов или отправка трафика через контролируемую точку подключения, прокси в GitHub Actions становится частью инфраструктуры CI/CD. Однако пароли, указанные непосредственно в YAML, вывод конфигурации для диагностики или использование одной учётной записи в нескольких проектах могут привести к утечке учётных данных.

Правильный подход — хранить конфиденциальные данные в GitHub Actions Secrets, предоставлять их только тем шагам, которым они нужны, и контролировать исходный код, которому разрешено выполняться с доступом к секретам. В статье рассматриваются организация, настройка и эксплуатация прокси по принципу минимальных привилегий.

Почему необходимо защищать учётные данные прокси?

Учётная запись прокси может позволять пользоваться сетевыми сервисами, обращаться к внутренним ресурсам или создавать трафик от имени организации. При утечке этих данных риски связаны не только с расходами на использование, но и с объёмом доступа, предоставленного прокси.

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

Выбор области хранения GitHub Actions Secrets

Секреты репозитория для настроек отдельного проекта

Секреты репозитория подходят, когда учётные данные используются только в одном репозитории. Пользователь с правами управления может открыть раздел Settings → Secrets and variables → Actions и создать секрет. Не указывайте пароли в файлах рабочих процессов и не добавляйте в коммиты конфигурационные файлы с уже заполненными данными для входа.

Секреты окружения для отдельных сред развёртывания

Если процесс предусматривает тестовую и производственную среды, рекомендуется использовать отдельные учётные записи прокси и соответствующие секреты окружений. Чтобы использовать эти секреты, задание должно объявлять соответствующее окружение.

В сочетании с правилами защиты окружения, например требованием одобрения или ограничением веток развёртывания, это помогает контролировать момент предоставления секретов. Доступность отдельных правил зависит от тарифного плана и типа репозитория.

Секреты организации для совместного использования

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

Подготовка параметров прокси перед сохранением

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

• PROXY_HOST: адрес прокси-сервера.
• PROXY_PORT: порт подключения, предоставленный администратором.
• PROXY_USERNAME: имя учётной записи для CI/CD.
• PROXY_PASSWORD: пароль учётной записи.
• NO_PROXY: список адресов для прямого подключения, если это разрешено сетевой политикой.

Пароль должен храниться как секрет. Адрес сервера и порт можно хранить в GitHub Actions Variables, если они не являются конфиденциальными; если они раскрывают структуру внутренней сети, их следует защищать соответствующим образом. Не используйте Variables для хранения учётных данных.

Другой вариант — сохранить полный URL с учётными данными в секрете PROXY_URL. Это уменьшает количество операций по объединению строк, но делает весь URL конфиденциальными данными. Выбирайте подход с учётом требований инструмента и процедуры ротации учётных данных.

Как создать секрет и использовать его в рабочем процессе

Создание секрета в нужной области

1. Определите репозиторий, окружение или группу репозиториев, которым требуется прокси.
2. Откройте страницу управления секретами Actions в соответствующей области.
3. Создайте секрет с понятным именем, соблюдая единую схему именования.
4. Введите фактическое значение и сохраните его; не указывайте пароль в описании или документации.
5. Проверьте политику доступа перед запуском рабочего процесса.

После сохранения значение секрета нельзя повторно прочитать через обычный интерфейс управления. Поэтому для обновления и отзыва учётных данных необходим утверждённый источник их хранения и управления, а не личные заметки.

Передача секрета в переменные окружения шага

В YAML рабочего процесса используйте раздел env, чтобы связать переменную шага с выражением секрета. Например, значением переменной PROXY_PASSWORD будет ${{ secrets.PROXY_PASSWORD }}. Если сохранён полный URL, инструмент с поддержкой переменных HTTP_PROXY или HTTPS_PROXY может получать значение из ${{ secrets.PROXY_URL }}.

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

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

Настройка прокси CI/CD с учётом используемого инструмента

Не все приложения читают одинаковые переменные окружения

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

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

Обработка специальных символов в учётных данных

Когда имя пользователя или пароль включены в URL, такие символы, как @, двоеточие или косая черта, могут изменить разбор адреса. Необходимо кодировать часть с учётными данными по правилам URL, а не произвольно кодировать всю строку.

Закодированное значение по-прежнему остаётся секретом. Не выводите собранный URL для проверки: механизм маскирования секретов не гарантирует распознавание всех преобразованных вариантов. Если инструмент поддерживает отдельные поля для имени пользователя и пароля, стоит рассмотреть их использование, чтобы снизить риск ошибок обработки URL.

Не отключайте проверку сертификатов TLS

Переменная HTTPS_PROXY обычно указывает прокси для запросов к HTTPS-ресурсам; само имя переменной не гарантирует шифрование соединения с прокси. Необходимо проверить протокол подключения и механизм аутентификации, поддерживаемые сервером.

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

Предотвращение утечек паролей через логи и выходные данные

GitHub Actions маскирует секреты в логах, но это не обеспечивает полной гарантии защиты. Закодированные, разделённые на части или преобразованные значения могут не распознаваться как исходный секрет.

• Не выводите все переменные окружения командами вроде env или printenv на шаге, которому доступны секреты.
• Не включайте трассировку оболочки, например set -x, при работе с учётными данными.
• Ограничивайте использование подробного вывода, который может показывать URL, заголовки или параметры подключения.
• Не включайте пароли в имена артефактов, выходные данные задания или сводку рабочего процесса.
• Не загружайте в артефакты и не сохраняйте в кеш конфигурационные файлы прокси, содержащие пароли.

Если во время выполнения необходимо создать новое конфиденциальное значение, можно зарегистрировать его для маскирования командой рабочего процесса add-mask до того, как оно появится в логах. Основная мера защиты — не выводить секреты вообще, а не рассчитывать на их последующее маскирование.

Контроль рабочих процессов, которым доступны секреты

Не предоставляйте секреты недоверенному исходному коду

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

Будьте особенно осторожны с pull_request_target: это событие выполняется в контексте целевого репозитория. Получение и последующее выполнение кода из пул-реквеста в задании с доступом к секретам могут привести к утечке учётных данных. Отделяйте проверку внешнего кода от задач, которым нужны секреты.

Проверка действий, скриптов и повторно используемых рабочих процессов

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

В повторно используемые рабочие процессы передавайте только необходимые секреты. Избегайте наследования всех секретов без явной необходимости. Также задавайте минимальные разрешения GITHUB_TOKEN; разрешения токена и право использования пароля прокси — две отдельные области, которые нужно контролировать независимо.

Управление раннерами и временными конфигурационными файлами

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

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

При сборке Docker не передавайте пароль через ARG и не записывайте его в ENV в Dockerfile для загрузки пакетов. Предпочитайте подходящий механизм секретов сборки и проверяйте, чтобы пароль не попадал в слои, кеш или итоговый образ.

Ротация учётных данных и реагирование на инциденты

Учётная запись прокси для CI/CD должна быть отделена от личных учётных записей и иметь только необходимые права. Если сервис поддерживает такую возможность, ограничивайте адреса назначения и источники подключений либо используйте краткосрочные учётные данные, подходящие для используемой модели раннеров.

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

При подозрении на утечку прежде всего отзовите или замените учётные данные. Затем проверьте логи, артефакты, кеш и историю доступа. Удаление строки из лога не гарантирует, что секрет ещё не был скопирован.

Контрольный список перед началом эксплуатации

• Храните пароли в GitHub Actions Secrets, а не в исходном коде.
• Выбирайте правильную область: репозиторий, окружение или организация.
• Предоставляйте секреты только необходимым шагам и доверенному исходному коду.
• Проверяйте, как инструмент читает переменные прокси и обрабатывает специальные символы.
• Сохраняйте проверку TLS и контролируйте доверенные сертификаты.
• Исключайте учётные данные из логов, артефактов, кеша и образов.
• Подготовьте процедуры ротации, отзыва и расследования инцидентов.

Безопасное использование прокси в GitHub Actions не сводится к хранению пароля в Secrets. Эффективность защиты зависит от всего жизненного цикла использования: предоставления прав в нужной области, корректной передачи данных, контроля выполняемого кода и своевременного отзыва доступа. При последовательном применении этих принципов конфигурацию прокси CI/CD становится проще поддерживать и проверять.