Многие думают, что положить секреты в Secrets в настройках репозитория - это всё, можно расслабиться. Но есть нюансы:
1️⃣ Secrets = env vars
В рантайме GitHub Actions подставляет секреты как переменные окружения. Их легко случайно вывести в лог, если бездумно делать
echo $SECRET_KEY. Логи сохраняются, а доступ к ним могут получить коллеги с правами на Actions.2️⃣ Маскирование работает не всегда
GitHub пытается автоматически маскировать значения секретов в логах. Но если у тебя секрет - это, например, base64 строка или JSON, маскировка может сработать криво. Тут уже сам контролируешь вывод.
3️⃣ Не храни много секретов в репозитории
Лучше использовать GitHub OIDC (OpenID Connect) и получать временные креды от AWS, GCP или Azure прямо в рантайме. Так ты избежишь постоянных ключей в Secrets.
4️⃣ Используй environments
В GitHub есть Environments с отдельными секретами и правилами доступа. Можно разграничить staging/prod, включить approvals перед деплоем. Это must-have.
5️⃣ Проверяй permissions у Actions
По умолчанию GitHub даёт job полный доступ к GITHUB_TOKEN. Иногда достаточно
permissions: read-only, а не write-all. Меньше прав → меньше дыр.💡Для управления секретами в масштабах компании лучше интегрировать GitHub с HashiCorp Vault, Doppler или AWS Secrets Manager. Тогда GitHub Secrets будет только точкой входа, а не хранилищем всего подряд.
Подпишись 👉@devopslib