Несанкционированный egress может выглядеть как здоровый сервис. Сценарий отказа: pod устанавливает соединения с посторонним IP:443, readiness зелёный, ошибок нет. Поверхностный мониторинг рапортует о доступности. В datapath Cilium тоже всё штатно: политика разрешает выход. Отказ здесь — разрыв между регламентом и реально применёнными ограничениями egress. Начинаем с hubble observe --from-pod prod/api-0 --verdict FORWARDED --follow. Сопоставляем назначения с разрешёнными зависимостями приложения. FORWARDED означает, что наблюдаемая точка datapath пропустила трафик; это не подтверждение доставки и не доказательство легитимности. IP:443 не раскрывает содержимое TLS. Hubble даёт метаданные потока без обязательного захвата payload через tcpdump, но генерация, экспорт и хранение событий расходуют ресурсы. Проверяем полноту наблюдения: hubble status, сообщения о потерянных событиях, доступность всех нужных узлов. Буфер конечен: отсутствие записи не доказывает отсутствие соединения. Параллельно снимаем дельты nstat -az TcpRetransSegs и /proc/net/softnetstat: второй столбец — dropped, третий — timesqueeze, значения шестнадцатеричные. Это признаки сетевого давления, а не детектор чужого egress. Здоровые счётчики ядра вполне совместимы с утечкой данных. Исправление — egress default-deny для выбранных workload и явные разрешения необходимых зависимостей, включая DNS. Затем проверяем разрешённые соединения и контролируемую попытку запрещённого выхода: ожидаем блокировку и соответствующее событие. Детектор строим на сравнении наблюдаемых назначений с разрешёнными; Hubble сам не знает ваш регламент. Покупка очередного дашборда этот пробел не закрывает. Практика эксплуатации: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=cilium-hubble-flow-logs-detektsiya-ne