0%

Sensitive-данные в манифестах

Уровень: expert ~35 мин Практика: Umami (продолжение) (MIT)

Что нужно знать перед уроком

  • M4.06 — Секреты в шаблонах — нужно понимание werf_secret_file и общей модели секретов Werf/Nelm

Что нужно знать перед уроком

M4 урок 6 — как секреты попадают в шаблоны. Этот урок закрывает отдельный, но смежный вопрос: как скрыть содержимое чувствительных полей из вывода nelm release plan/werf plan, независимо от того, откуда эти данные взялись.

Теория

werf.io/sensitive: "true" — маркировка всего ресурса

1

"werf.io/sensitive": "true"

По умолчанию Nelm/Werf показывают diff (изменения между текущим состоянием кластера и новым рендером) для всех ресурсов при plan, кроме Secret — для Secret diff скрыт всегда, автоматически, без необходимости в явной аннотации. Аннотация werf.io/sensitive: "true" расширяет это поведение на любой другой тип ресурса (ConfigMap, CustomResource с чувствительными полями и т.д.), полностью скрывая diff для него в выводе plan.

Актуальный статус аннотации: в актуальной документации Nelm werf.io/sensitive помечена как deprecated в пользу werf.io/sensitive-paths — аннотация продолжает работать (полное скрытие diff всего ресурса), но для нового кода официально рекомендуется сразу использовать sensitive-paths, даже если нужно скрыть весь ресурс целиком (достаточно перечислить путь $ или все чувствительные поля явно).

werf.io/sensitive-paths — точечная маркировка отдельных полей

1

"werf.io/sensitive-paths": "$.spec.template.spec.containers[*].env[*].value,$.data.*"

В отличие от sensitive (скрывающей diff всего ресурса), sensitive-paths принимает список JSONPath-выражений, скрывающих diff только для конкретных полей, оставляя остальную часть diff видимой — что полезно, например, для Deployment, где значения env могут содержать чувствительные данные, но остальная конфигурация (образ, реплики, ресурсы) должна оставаться видимой для полноценного code review изменений в CI.

Важное уточнение по приоритету: sensitive-paths переопределяет (override) поведение sensitive — то есть можно, например, установить sensitive: "true" для всего ресурса, но при этом явно не указывать конкретное поле в sensitive-paths, тем самым сделав это единственное поле видимым, даже когда весь остальной ресурс скрыт (или наоборот — оставить ресурс полностью открытым, но замаскировать только пару чувствительных путей).

Зачем это нужно при уже зашифрованных secret-values.yaml

Может показаться, что если значения и так зашифрованы в git через secret-values.yaml (M4 урок 2), скрывать diff не нужно — но это отдельная задача: secret-values.yaml защищает данные в git-репозитории, а sensitive/sensitive-paths защищает их в выводе CI/CD (логи GitLab CI job, куда werf plan/nelm release plan печатает итоговый diff перед применением) — расшифрованное значение пароля, оказавшееся в открытом виде в логе CI, доступном всей команде разработки, это утечка данных независимо от того, насколько хорошо оно было зашифровано в самом репозитории.

Частые ошибки и подводные камни

  • Полагать, что шифрование secret-values.yaml автоматически скрывает diff в CI. Это два разных, независимых механизма защиты — шифрование в git не защищает от вывода расшифрованного значения в лог CI при plan.
  • Не знать, что Secret уже скрыт по умолчанию. Добавление werf.io/sensitive: "true" к ресурсу типа Secret избыточно — эта защита уже встроена по умолчанию для всех ресурсов этого kind.
  • Использовать sensitive вместо sensitive-paths там, где нужен частичный обзор diff. Полное скрытие всего ресурса лишает code review возможности увидеть изменения в НЕчувствительных полях того же ресурса (например, изменение replicas в том же Deployment, где также меняется чувствительный env).
  • Продолжать писать новые манифесты с werf.io/sensitive, не зная о его статусе deprecated. Аннотация по-прежнему работает, но актуальная документация Nelm рекомендует sensitive-paths как единственный способ маркировки чувствительных данных для нового кода.

Практика в кластере

🧩 Практика урока: Umami (продолжение) · лицензия MIT
1
2
3

d8 k annotate deployment umami-app -n course-m6-umami \
  'werf.io/sensitive-paths=$.spec.template.spec.containers[*].env[*].value' --overwrite
nelm release plan install -n course-m6-umami -r umami .

Сравните вывод plan до и после добавления аннотации — убедитесь, что значения env скрыты, а остальной diff (например, изменение image) по-прежнему виден.

Практика разработки

Добавьте werf.io/sensitive-paths к Deployment пакета Umami для полей, содержащих переменные окружения с секретами БД (DATABASE_URL), сохранив видимость остального diff для полноценного code review в GitLab CI merge request.

Шпаргалка команд урока

Sensitive-аннотации — 📋 nelm .

Вопросы для самопроверки

Скрывается ли diff для ресурсов типа Secret по умолчанию, без явных аннотаций?

Это единственное исключение из общего правила показа diff по умолчанию.

Источник: Werf — документация — Mark Resource as Sensitive

Чем sensitive-paths отличается от sensitive?

Точечный контроль позволяет сохранить видимость остального diff для code review.

Источник: Werf — документация — Mark Resource Fields as Sensitive

Защищает ли шифрование secret-values.yaml автоматически от появления расшифрованного значения в логе CI при werf plan?

Важное разграничение зон ответственности двух разных механизмов защиты данных.

Источник: Рекомендуемая литература

Может ли sensitive-paths переопределить поведение sensitive для конкретного поля?

Явно указано в документации werf — sensitive-paths override поведение sensitive.

Источник: Werf — документация — Reference > Deploy Annotations

Рекомендуемая литература

Официальная документация

Статьи и блоги

Книги

  • Matt Butcher, Matt Farina, Josh Dolitsky. Learning Helm. 2019. ISBN 978-1492036781.

Связанные материалы