Управление секретами GitHub Actions: защита ключей API и паролей в рабочих процессах

By Mirko Peters · 2026-10-26

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

Automatically translated with AI from the original post. Read the English original

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

Главное

• Никогда не прописывайте пароли, ключи API или токены доступа напрямую в YAML-файлах рабочих процессов.
• GitHub предоставляет три уровня секретов: секреты репозитория, секреты организации и секреты среды.
• Секреты шифруются еще до того, как попадают в GitHub, и автоматически маскируются в журналах выполнения.
• Секреты среды могут требовать ручного подтверждения, прежде чем учетные данные для развертывания станут доступны заданию.
• Всегда придерживайтесь принципа наименьших привилегий, предоставляя каждому секрету минимально необходимый набор разрешений.

Почему открытые учетные данные не работают в CI/CD

Разработчикам, которые спешат настроить новый конвейер, соблазнительно вставить ключ API прямо в файл конфигурации рабочего процесса. Ведь если рабочий процесс приватный, кто его увидит? Такой подход создает серьезные уязвимости безопасности. Файлы рабочих процессов находятся под контролем версий, а это значит, что каждая историческая ревизия, коммит и ветка навсегда сохраняют всё, что было записано в этих YAML-документах.

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

Три уровня секретов GitHub

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

Секреты уровня репозитория

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

Секреты уровня организации

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

Секреты уровня среды

Секреты среды привязывают учетные данные к конкретным целям развертывания, таким как среды staging или production. Здесь хранятся ключи, необходимые для работы с действующими системами. Важно то, что секреты среды позволяют настроить обязательных рецензентов: человек должен вручную подтвердить запуск развертывания, прежде чем производственные учетные данные будут раскрыты и переданы исполнителю.

Как GitHub защищает ваши данные при передаче

Безопасность — это не только вопрос того, где хранятся секреты, но и того, как они передаются во время выполнения. Секреты шифруются на вашем локальном компьютере до передачи в GitHub, так что по сети они никогда не отправляются в открытом виде. После сохранения они полностью скрыты в интерфейсе настроек репозитория.

Когда выполняется рабочий процесс, вы должны явно передать секрет в шаг или действие по имени, используя синтаксис выражений, например ${{ secrets.DATABASE_URL } }. Это означает, что сторонний действие из маркетплейса, даже если оно случайно или намеренно вредоносное, не сможет самостоятельно забрать все учетные данные из вашего репозитория — оно получит только то, что вы сами ему передали.

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

Лучшие практики безопасной автоматизации

Надежное управление секретами GitHub Actions требует выработки определенных повседневных привычек. Во-первых, всегда различайте настройку и секрет. Если значение представляет собой просто публичный адрес сайта, имя среды или некритичный флаг функции, храните его открытым текстом в файле YAML, чтобы команда могла легко понять, как работает конвейер. Функциональность секретов приберегайте исключительно для данных, которые должны оставаться конфиденциальными.

Во-вторых, придерживайтесь принципа наименьших привилегий. Создавайте токены доступа с минимально возможным сроком действия и максимально узким набором разрешений. Если токену развертывания нужно только записывать данные в один конкретный сегмент S3, не давайте ему административных прав над всей вашей облачной инфраструктурой.

Заключение

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

Чтобы разобраться в основах создания автоматизированных рабочих процессов, посмотрите Listen to the full episode. Присоединяйтесь к полному обсуждению, чтобы узнать больше о настройке триггеров, заданий и исполнителей для вашей современной облачной среды!

Часто задаваемые вопросы

Могу ли я получить доступ к секрету GitHub Actions в запросе на извлечение (pull request) из форка?

По умолчанию GitHub запрещает запросам на извлечение от внешних участников (из форков) доступ к секретам репозитория, чтобы защитить учетные данные от выполнения вредоносного кода и их кражи.

Как передать секрет из рабочего процесса в конкретный шаг?

Секреты передаются в workflow через контекст 'env' на уровне шага или задания: секрет GitHub сопоставляется с переменной окружения, например env: API_KEY: ${{ secrets.MY_API_KEY } }.

Гарантированно ли секреты GitHub Actions скрыты в журналах?

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

В чем разница между секретами репозитория и секретами среды?

Секреты репозитория доступны любому рабочему процессу в данном репозитории, тогда как секреты среды привязаны к конкретным средам развертывания (например, staging или production) и могут требовать ручного одобрения.