Skip to content
Exlogare
← Ко всем постам
Команда Exlogare CI/CD security logs DevOps

Как безопасно передавать CI-логи наружу без утечки секретов

Практичный чеклист для junior/middle инженеров: какие части CI-лога можно отправлять во внешний анализ, что надо вырезать заранее и как не превратить диагностику в утечку токенов.

CI-лог часто выглядит безобидно: несколько тысяч строк сборки, тестов и деплоя. Но внутри легко оказываются токены, URL с basic auth, переменные окружения, имена внутренних сервисов и куски тестовых данных. Поэтому вопрос не в том, «можно ли отправлять лог наружу», а в том, какую часть лога, после какой очистки и на какой срок.

Эта статья для тех, кто уже пользуется GitLab CI, GitHub Actions, Jenkins или TeamCity, но не хочет становиться специалистом по security, чтобы подключить диагностику падений.

Коротко для тех, кто впервые с этим сталкивается

CI-лог — это текстовый вывод job: команды, stdout/stderr, stack trace, сообщения тестов и иногда debug-информация инструментов. Redaction — это замена секретов на безопасные маркеры вроде [REDACTED_TOKEN]. RCA (root cause analysis) — короткий разбор: что упало, почему и что проверить первым.

Безопасная передача логов строится на трёх принципах:

  • отправлять только то, что нужно для диагностики;
  • вырезать секреты до отправки;
  • не хранить raw log дольше, чем нужно.

Что не стоит отправлять целиком

Не отправляйте наружу весь pipeline log «на всякий случай». В больших проектах он может содержать:

  • вывод env, printenv, set -x;
  • параметры Terraform, Helm, kubectl;
  • тестовые дампы БД и fixture-данные;
  • URL вида https://user:password@host;
  • stack trace с payload'ами запросов;
  • debug-вывод package manager'ов.

Чаще всего для первичного RCA хватает последних 200–500 строк упавшего шага плюс метаданные: provider, проект, branch, commit SHA, job name, exit code и ссылка на pipeline.

Минимальный безопасный контур

  1. Включите masked/protected variables в CI-системе.
  2. Не печатайте секреты через echo, env, set -x.
  3. Отправляйте только failed job, а не весь pipeline.
  4. Перед отправкой прогоняйте лог через redaction: токены, JWT, приватные ключи, AWS/GCP keys, basic-auth URL.
  5. Ограничьте retention: raw log нужен для анализа сейчас, а не через полгода.
  6. Подписывайте webhook или используйте токен API с минимальными правами.

Что важно не вырезать

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

  • имя job и stage;
  • package/service name;
  • exit code;
  • версия образа или runtime;
  • путь к файлу/тесту;
  • номер build/pipeline/job;
  • последние строки stack trace.

Например, npm ERR! code E401 без package registry и команды установки почти бесполезен. А вот токен из .npmrc нужно заменить на [REDACTED_NPM_TOKEN].

Где тут Exlogare

Exlogare лучше подключать не как «хранилище всех логов», а как сервис, который получает короткий sanitized failure context и возвращает RCA туда, где команда уже работает: в MR/PR или рядом со статусом pipeline. Такой подход снижает риск утечки и убирает ручной этап «прочитай весь лог и объясни в чате».

Если вы хотите проверить свой контур, начните с документации по ingest API или generic-интеграции через curl из CI. Для требований к обработке данных посмотрите страницу Security.

Читайте также

Чеклист перед отправкой логов

  • В лог не попадает env/printenv целиком.
  • CI masking включён для всех токенов.
  • Отправляется только failed step tail.
  • Redaction запускается до внешнего API.
  • Есть ограничение retention.
  • Webhook/API вызов аутентифицирован.
  • RCA сохраняется отдельно от raw log.