Куда смотреть
Ищите API Audit kube-apiserver: политика аудита определяет записываемые данные, а механизм сохранения — куда они поступают. Kubernetes Event API и Audit Event — разные сущности. Устройство аудита.
Как проверить действие
- Выбрать нужный кластер и период, проверить правила отбора и сохранение нужных событий.
- Найти
verb=createи объект ресурсаpods. - Сопоставить стадии по
auditID; изучитьResponseCompleteи результат запроса. - Проверить
user.username, impersonation и объект. Контроллер мог создать Pod от имени ServiceAccount; для поиска первоначального инициатора может потребоваться действие над Deployment или другим владельцем.
Пример
Пример, не полный экспорт кластера:
{"auditID":"demo-request-01","verb":"create","stage":"ResponseComplete","user":{"username":"system:serviceaccount:demo:controller"},"objectRef":{"resource":"pods","namespace":"demo","name":"demo-pod"},"responseStatus":{"code":201}}
Имена полей сверяются с Audit API v1. Значения примера придуманы для объяснения.
Поиск в копии журнала
Вкладка «Примеры» содержит jq-отбор из локального JSON Lines. Он не запускает kubectl и не меняет кластер. Файл и схема должны соответствовать экспорту; синтаксис jq.
Границы вывода
Запрос API не доказывает запуск приложения внутри контейнера. Нужна проверка результата и последующего состояния; журналы среды выполнения контейнеров и EDR — отдельные источники. Отсутствие записи аудита может объясняться правилами отбора, сроком хранения и доставкой.
Паспорт среды перед выборкой
Зафиксируйте кластер, фактическую версию kube-apiserver, namespace, период и UTC-смещение, место получения журнала, политику аудита, механизм сохранения и формат экспорта. audit.k8s.io/v1 обозначает схему записи, а не версию установленного Kubernetes. Убедитесь, что политика аудита сохраняет нужный ресурс, действие и стадию. JSON Lines в jq-выборке — локальная копия данных, не доступ к работающему API.
Как читать результат выборки
В примере выше verb=create, ресурс pods, стадия ResponseComplete, результат 201. Это положительный результат запроса API в показанном примере. Запрос и стадии связываются по auditID; одинаковые стадии не считать новыми созданиями. user.username — ServiceAccount контроллера, поэтому найден технический инициатор этого API-запроса, а не обязательно человек, изменивший Deployment.
Сверьте namespace, имя, доступный UID объекта и временной интервал. При наличии impersonatedUser сохраните и исходную, и подставленную идентичность. Ответ с 403 означал бы отказ; один RequestReceived без конечной стадии не устанавливает успех. Выборка не должна превращать любой найденный запрос в вывод «контейнер запущен».
Следующий этап расследования
Если инициатор — контроллер, проследите владельца Pod и административный запрос к Deployment/Job или другому управляющему объекту, когда такие данные доступны. Состояние Pod и сведения среды выполнения контейнеров проверяйте отдельно. Для вопроса о команде внутри контейнера нужен следующий запрос exec и другие источники; это другой этап.
Если выборка пуста
Проверьте ресурс, verb, namespace, регистр полей, интервал и стадию. Уточните, был ли аудит настроен во время действия, не отбросили ли запись правила аудита, сохранены ли нужные события за выбранный период. Сравните исходную копию с доставленным файлом и не считайте пустой jq-результат доказательством отсутствия API-запроса. Не меняйте действующую политику аудита только ради этой проверки без отдельного согласования эксплуатации.