Стежити Де знаходяться журнали аудитів Kubernetes, залежить від того, хто керує вашим контрольним вузлом. У кластері з самостійним управлінням вони є файлом JSON-ліній на вузлі контрольного рівня, за шляхом, на який вказує –audit-log-path. На EKS вони надсилаються до CloudWatch Logs, на AKS – у робочий простір Log Analytics або обліковий запис сховища, а на GKE – у Cloud Audit Logs. Одне залишається скрізь: аудит повинен бути увімкнений. На кластерах з самостійним управлінням та EKS він вимкнений, доки хтось не активує його.
Журнал аудиту фіксує кожен запит до API Kubernetes: хто виконав kubectl exec в якийсь под, хто прочитав який секрет, хто прив’язав себе до cluster-admin. Prime Core має 93 правила виявлення для даних аудиту Kubernetes, які відображаються на 220 техніках MITRE ATT&CK. Серед них: виконання в запущені контейнери (T1609), розгортання злоякісних контейнерів (T1610) і читання облікових даних через API контейнерів (T1552.007).
Перш ніж ви почнете
Чи увімкнено?
| Платформа | Де перевірити |
|---|---|
| З самостійним управлінням (kubeadm і подібні) | –audit-policy-file і –audit-log-path на сервері API; з kubeadm, у /etc/kubernetes/manifests/kube-apiserver.yaml |
| EKS | Кластер → Спостережуваність → логування контрольної площини, тип журналу “audit” |
| AKS | Налаштування діагностики на кластері, категорії kube-audit або kube-audit-admin |
| GKE | Увімкнено за замовчуванням для Адміністративної діяльності; логування доступу до даних для Kubernetes є додатковим |
Якщо воно не було увімкнено, немає чого експортувати за минулий час, і решта цього керівництва стосується наступного разу.
Деталі залежать від політики. На рівні Метаданих ви бачите, хто що зробив з яким об’єктом. На рівні Запиту або Запит-Відповідь ви також бачите тіла, наприклад, специфікацію пода, що запросила привілейованість: істина. Знайте, який у вас є, перш ніж шукати.
Очікуйте обсяг. Контролери та облікові записи сервісів постійно взаємодіють з API. На AKS, kube-audit-admin пропускає тільки для читання операції get і list, що зберігає розмір, але також приховує прочитання секретів.
Експортуйте це
Кластер з самостійним управлінням, на вузлі контрольної площини:
# спочатку підтвердьте шлях
sudo grep -- '--audit-log-path' /etc/kubernetes/manifests/kube-apiserver.yaml
sudo cat /var/log/kubernetes/audit/audit.log > k8s_audit.jsonl
Переміщені файли (від –audit-log-maxbackup) знаходяться поруч з відміткою часу у назві. Додайте їх, якщо вікно сягає назад.
EKS, з CloudWatch Logs:
aws logs filter-log-events --log-group-name /aws/eks/my-cluster/cluster
--log-stream-name-prefix kube-apiserver-audit
--start-time $(date -d '2026-10-19T00:00:00Z' +%s000) --end-time $(date -d '2026-10-20T00:00:00Z' +%s000)
--output json | jq -c '.events[].message | fromjson' > eks_audit_1019.jsonl
Кожна подія CloudWatch обертає вхід аудиту у вигляді строку; fromjson розгортає її. Синтаксис date -d є GNU; на macOS, обчисліть тимчасові мітки в мілісекундах іншим чином.
AKS, з Log Analytics (ресурсно-специфічні таблиці):
az monitor log-analytics query -w <workspace-id>
--analytics-query "AKSAuditAdmin | where TimeGenerated between (datetime(2026-10-19) .. datetime(2026-10-20))"
--output json > aks_audit_1019.json
GKE, з Cloud Audit Logs:
gcloud logging read 'resource.type="k8s_cluster" AND logName:"cloudaudit.googleapis.com" AND timestamp>="2026-10-19T00:00:00Z" AND timestamp<"2026-10-20T00:00:00Z"'
--project=my-project --format=json | jq -c '.[]' > gke_audit_1019.jsonl
Що шукати
| Запит | Чому це важливо |
|---|---|
| створити на pods/exec (objectRef.subresource: exec) | Хтось відкрив оболонку в запущеному контейнері |
| створення ClusterRoleBinding до cluster-admin | Ескалація привілеїв до повного контролю |
| отримати або перерахувати секрети незвичайною особою | Збирання облікових даних |
| Поди створені з привілейованими, hostPath або hostNetwork | Крок до виходу на вузол |
| user.username: system:anonymous з відповіддю 2xx | Анонімний доступ, який не повинен працювати |
| Ривки 403 з одного облікового запису сервісу | Вкрадений токен, що відчуває свої дозволи |
Завантажити, очистити та переглянути у LogTotal
- Завантажити. Відкрити logtotal.com і вибрати файл .jsonl.
- Очистити. [what gets masked: usernames, service account names, source IPs, namespaces, object names]. Look it over before you continue.
- Переглянути.
Коли все йде не так
| Симптом | Ймовірна причина | Fix |
|---|---|---|
| Немає файлу аудиту на контрольній площині | Сервер API не має налаштованої політики аудиту | Очікується; налаштуйте це на майбутнє |
| Відсутня група журналів або потоки аудиту EKS | Тип журналу “audit” контрольної площини не увімкнений | Увімкніть це на майбутнє |
| Кожен рядок – це один довгий екранований рядок | Обгортка CloudWatch | Розгорніть з використанням fromjson, як вище |
| Ви можете бачити, хто змінив под, але не як | Політика на рівні Метаданих | Підвищте рівень для чутливих ресурсів |
| Не читаєть секрети в даних AKS | kube-audit-admin виключає запити get і list | Збирайте kube-audit, якщо вони вам потрібні |
FAQ
Чи достатньо логів контейнерів?
Ні. Логи контейнерів показують, що додаток надрукував. Журнал аудиту показує, що зробили люди і облікові записи сервісів у кластері. Різні питання, різні логи.
Чи можу я прочитати файл аудиту в керованому кластері?
Ні. На EKS, AKS і GKE ви не маєте доступу до вузлів контрольної площини. Служба журналювання провайдера є єдиним маршрутом.
