Условия и источник
Зафиксируйте кластер, версию API server, audit policy, backend и период. Здесь рассматривается запрос к pods/exec, а не полный журнал команд внутри контейнера. Уровень и стадии аудита определяют доступную форму записи. API audit.k8s.io/v1 — версия схемы, не выпуск кластера. Работайте с полученной копией, не открывая интерактивный exec для проверки наличия следов.
Как отобрать запись
Отберите objectRef.resource=pods и subresource=exec в audit JSONL. Сгруппируйте сохранённые стадии по auditID с учётом источника; одну стадию нельзя считать всей операцией. Для конкретного эпизода сохраните namespace/name, identity и requestURI при наличии. Не теряйте отказанные запросы при фильтрации только успешных HTTP-кодов: они отвечают на отдельный вопрос о попытке доступа.
Разбор примера
ResponseStarted в примере с Metadata показывает начало ответа для выбранного запроса. Иллюстративный 101 относится к смене протокола соединения и не является универсальным кодом всех exec. user.username указывает техническую identity API, а objectRef — целевой Pod. Показанное подмножество не содержит stdout, stderr, exit code или полного результата команды; эти данные нельзя достроить из факта установления канала.
Интерпретация и границы
Разделяйте разрешение API-запроса, установление потока и фактический процесс внутри контейнера. ServiceAccount или пользовательский токен не устанавливает человека без дополнительной цепочки. Имя Pod может переиспользоваться, поэтому сохраняйте UID, когда доступен, и время. Для запроса через другой транспорт/метод проверяйте фактический verb и URI, не требуя от всех событий точного совпадения с учебной иллюстрацией.
Следующая проверка
Сопоставьте эпизод с состоянием Pod, узлом, контейнером и доступными процессными данными runtime/хоста. Для оценки допуска проверьте действовавшие RBAC и основание работы, а для изменения файлов — отдельные свидетельства. Запишите, что именно установлено: запрос, канал или выполнение процесса. Не называйте выводом команды сообщение API и не объявляйте успех приложения по одному transport status.
Если записи нет
Проверьте, охватывала ли policy именно подресурс pods/exec, какие стадии исключались и куда сохранял backend. Затем уточните период, retention и потери доставки. Логи API audit и обычные Kubernetes Events — разные источники. Отсутствие exec в доступной копии не исключает процесс, запущенный иным способом, а отсутствие тела при Metadata является ограничением формата, не ошибкой аналитика.