Данные и безопасность
Что уходит с узла, кто это видит и что со временем удаляется.
Собираемые и исключённые данные
Заголовок раздела «Собираемые и исключённые данные»В зависимости от включённых профилей наблюдение может нести идентичности нагрузки и процесса, имена исполняемых файлов, системные вызовы, сетевые адреса и порты, DNS-имена с ограниченными ответами, метаданные путей, время и сведения о завершении. Содержимого там нет, и всё же имена, пути и адреса сами по себе могут многое рассказать о вашем бизнесе. Именно поэтому держите селекторы и префиксы путей узкими.
Содержимое файлов, буферы записи, переменные окружения и произвольные аргументы команд не собираются. Наблюдение DNS не выгружает сырые пакеты и ничего не расшифровывает. Это ни захват трафика, ни резервная копия файловой системы. Доступ к сайту и API ограничен вашей организацией, а в этой публичной документации её наблюдений нет: снимки экрана в ней сделаны на примерных данных.
Права агента и токены
Заголовок раздела «Права агента и токены»Эталонный агент работает с hostPID, смонтированными только для чтения /proc и cgroup узла и доступным для записи tracefs — иначе он вообще не подключит зонды. Он запускается от root с явным набором возможностей: BPF, NET_ADMIN, PERFMON, SYS_ADMIN и SYS_RESOURCE, а не в общем privileged-режиме. Его RBAC читает Pod, ReplicaSet, Deployment и идентичность пространства имён kube-system; менять нагрузки и читать Secret через API он не может. Это права на уровне узла, поэтому разберите их с оператором до установки.
Люди входят под индивидуальными сессиями. Агенты используют отдельные версионированные токены приложений, и сервер хранит только их дайджесты. Ротация выглядит так: выпустите дополнительный токен, обновите смонтированный Secret, выполните rollout DaemonSet, убедитесь, что у нового токена появилось свежее время последнего использования, и только после этого отзовите старый. Горячей перезагрузки нет. Отзыв останавливает поток этого токена и не задевает другие приложения.
Подробности событий и числовая история
Заголовок раздела «Подробности событий и числовая история»Сроки хранения событий задают владельцы организации; проект либо наследует политику целиком, либо переопределяет её, а участники видят действующие значения. В новой установке очистка выключена, а сроки заданы так: 30 дней подробностей и 365 дней общей истории. raw_days — это срок жизни подробностей, а history_days — предельный возраст наблюдения, а не дополнительный период сверху. Бессрочная история означает вечные числа, а не вечные подробности.
Очистка идёт сама, ограниченными пакетами и по полным дням UTC. Остаётся сводка: счётчики и время первого и последнего наблюдения по группе, релизу и дню — но не содержимое событий и не подробности уровня Pod. Включение очистки, сокращение срока или возврат к включённой наследуемой политике могут удалить данные, которые у вас ещё есть. В обратную сторону это не работает: увеличенные сроки или отключённая очистка не вернут удалённые подробности и не откроют закрытую историю.
История уведомлений
Заголовок раздела «История уведомлений»У истории уведомлений свои сроки, не связанные со сроками событий: новая организация начинает с выключенной очисткой и окном в 90 дней. Владельцы управляют ими в профиле, проект может переопределить их в разделе уведомлений, а участникам доступно только чтение. Удаляются лишь доставки, дошедшие до конечного состояния, и отсчёт идёт от последнего такого перехода: всё, что ожидает, повторяется или выполняется, сохраняется.
Вместе с истёкшей доставкой удаляются её попытки и связанные подробности восстановления, и увеличение срока хранения потом их не вернёт. Поэтому, прежде чем включать или сокращать любую из политик, посмотрите на действующие настройки и на то, что вам действительно нужно сохранить. Очистка уведомлений и отправка webhook друг от друга не зависят.