Секреты в логах CI: 10 мест, где их обычно забывают
Docker login, npm verbose, Terraform debug, kubectl, echo переменных и артефакты тестов: где секреты чаще всего всплывают в CI-логах и что с этим делать.
Большинство утечек в CI-логах не выглядит как драматичная ошибка security-команды. Обычно это строка, которую кто-то добавил «на пять минут для отладки»: echo $TOKEN, set -x, terraform plan -debug, kubectl describe secret.
Эта статья — чеклист для новичков и мидлов: где искать секреты до того, как вы начнёте отправлять логи во внешний анализ, сохранять их в артефакты или пересылать в чат.
Коротко: что считать секретом
Секрет — это не только пароль. В CI-логе опасны:
- access tokens и refresh tokens;
- JWT;
- приватные ключи;
- cloud credentials;
- URL с логином и паролем;
- kubeconfig;
.npmrc,.pypirc,.docker/config.json;- тестовые данные с PII.
10 мест, где секреты всплывают чаще всего
1. docker login. Флаг --password и debug-вывод могут оставить пароль в истории команды. Безопаснее использовать --password-stdin.
2. npm/yarn/pnpm verbose. Ошибки авторизации иногда печатают registry URL и путь к .npmrc. Токен должен маскироваться, registry можно оставить.
3. Terraform debug. TF_LOG=DEBUG полезен, но легко показывает provider config, headers и значения переменных.
4. kubectl и Helm. kubectl describe secret, values-файлы Helm и rendered manifests могут вывести чувствительные поля.
5. set -x в shell. Bash печатает команды после подстановки переменных. curl -H "Authorization: Bearer $TOKEN" превращается в токен в логах.
6. echo для проверки переменных. «Проверю, что переменная приехала» — классика утечек. Печатайте длину или последние 4 символа, но не значение.
7. Тестовые дампы БД. Даже test fixtures могут содержать email, телефоны, имена клиентов или внутренние id.
8. Crash reports. Некоторые SDK кладут request headers и payload в stack trace.
9. Build args. Docker build args и output сборщика могут вывести значения, если они попали в команду.
10. Артефакты. В лог всё чисто, а в artifact.zip лежит .env, report.html или junit.xml с PII.
Как проверять логи перед интеграцией
Начните с простого поиска по последним падениям:
grep -Ei '(token|secret|password|authorization|bearer|aws_|private key|kubeconfig)' failed-job.log
Это не полноценный security scanner, но хороший smoke test. Для постоянного контура добавьте redaction перед отправкой лога наружу.
Где тут Exlogare
Exlogare полезен после того, как лог уже прошёл базовую гигиену: вы отправляете не весь артефакт сборки, а безопасный failure context. В ответ команда получает RCA в MR/PR: что упало, какая причина вероятна и что проверить первым.
Для GitLab начните с ingest GitLab CI, для GitHub Actions — с соответствующего гайда. Общие требования к данным — на странице Security.
Читайте также
- Как безопасно передавать CI-логи наружу без утечки секретов
- Артефакты и логи CI: что хранить, а что нельзя класть в S3 как есть
Чеклист
- В CI отключён
set -xвокруг секретов. docker loginиспользует--password-stdin.- Debug-режим Terraform/kubectl включается только точечно.
- В лог не печатаются raw env values.
- Артефакты проверяются так же, как логи.
- Перед отправкой наружу запускается redaction.