Библиотека девопса | DevOps, SRE, Sysadmin

🔥 GitHub Actions и секреты: как не словить утечку

Многие думают, что положить секреты в 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

👍1

www.tgoop.com/devopslib/108

602 viewsSep 4 at 06:36

🔥 GitHub Actions и секреты: как не словить утечку

Многие думают, что положить секреты в 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

BY Библиотека девопса | DevOps, SRE, Sysadmin