Lesson 0032 · 20 minutes · Monitoring, Logging, and Runtime Security
Separate a failed attack from a successful compromise
Suspicious intent is not the same as successful impact. Reconstruct the incident from the authenticated principal, affected resources, timestamps, and HTTP response codes.
Timed task: 12 minutes
Analyze lab/lesson-32-audit.jsonl with a structured JSON tool. Create lab/lesson-32-answer.md containing concise answers to these questions:
- Which suspicious RBAC request failed, who made it, and what evidence proves it failed?
- Which principal completed the successful attack sequence?
- What was the first successful escalation event? Include timestamp, verb, resource type, namespace, and resource name.
- Which credential-bearing object was accessed successfully?
- What runtime action followed?
- Give three immediate containment actions in operational order.
Also include the exact command you used. Do not identify a principal by audit ID, and do not describe a rejected request as a completed privilege escalation.
responseStatus.code before claiming impact. Then pivot on user.username, source IP, and time. Contain the authority first, isolate execution second, and rotate exposed credentials after access is stopped.PowerShell starting point
Get-Content .\lab\lesson-32-audit.jsonl |
ForEach-Object { $_ | ConvertFrom-Json } |
Select-Object requestReceivedTimestamp, verb,
@{n='principal';e={$_.user.username}},
@{n='code';e={$_.responseStatus.code}}, objectRef
Retrieval check
Question
An audit event shows a suspicious RBAC create request with response code 403. What can you conclude?
Documentation target
Use the official Kubernetes auditing documentation after your first attempt.
What to send me
Save the incident note, then say check. I will list all detected issues and help you correct only one per round. Ask me a follow-up question if any audit field is unclear.