Segui Dove si trovano i log di audit di Kubernetes dipende da chi gestisce il tuo piano di controllo. Su un cluster autogestito, sono un file JSON-lines sul nodo del piano di controllo, nel percorso indicato da –audit-log-path. Su EKS, vanno a CloudWatch Logs, su AKS in un’area di lavoro Log Analytics o un account di archiviazione, e su GKE nei Log di Audit Cloud. Una cosa è certa ovunque: il logging di audit deve essere attivato. Su cluster autogestiti ed EKS è disattivato fino a quando qualcuno non lo abilita.
Il log di audit registra ogni richiesta all’API di Kubernetes: chi ha eseguito kubectl exec in quale pod, chi ha letto quale segreto, chi si è associato a cluster-admin. Prime Core ha 93 regole di rilevamento per i dati di audit di Kubernetes, mappate su 220 tecniche MITRE ATT&CK. Tra esse: exec nei container in esecuzione (T1609), distribuzione di container canaglia (T1610) e lettura delle credenziali tramite l’API del container (T1552.007).
Prima di iniziare
È abilitato?
| Piattaforma | Dove controllare |
|---|---|
| Autogestito (kubeadm e simili) | –audit-policy-file e –audit-log-path sul server API; con kubeadm, in /etc/kubernetes/manifests/kube-apiserver.yaml |
| EKS | Cluster → Osservabilità → logging piano di controllo, tipo di log “audit” |
| AKS | Impostazioni diagnostiche sul cluster, categorie kube-audit o kube-audit-admin |
| GKE | Attivato per impostazione predefinita per l’attività amministrativa; il logging dell’accesso ai dati per Kubernetes è su base facoltativa |
Se non era attivato, non c’è niente da esportare per il passato, e il resto di questa guida riguarda la prossima volta.
Il dettaglio dipende dalla politica. A livello Metadata vedi chi ha fatto cosa a quale oggetto. A livello Request o RequestResponse vedi anche i contenuti, per esempio la specifica del pod che richiedeva privilegi: true. Sapere quale hai prima di cercare.
Aspettati volume. I controller e gli account di servizio parlano costantemente con l’API. Su AKS, kube-audit-admin omette le chiamate get e list in sola lettura, il che mantiene una dimensione ragionevole ma nasconde anche letture di segreti.
Esportalo
Cluster autogestito, su un nodo del piano di controllo:
# conferma prima il percorso
sudo grep -- '--audit-log-path' /etc/kubernetes/manifests/kube-apiserver.yaml
sudo cat /var/log/kubernetes/audit/audit.log > k8s_audit.jsonl
File ruotati (da –audit-log-maxbackup) si trovano accanto con un timestamp nel nome. Includili se la finestra si estende indietro.
EKS, da 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
Ogni evento CloudWatch avvolge la voce di audit come stringa; fromjson la disavvolge. La sintassi date -d è GNU; su macOS, calcola i timestamp in millisecondi in un altro modo.
AKS, da Log Analytics (tabelle specifiche delle risorse):
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, da Log di Audit Cloud:
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
Cosa cercare
| Richiesta | Perché è importante |
|---|---|
| create su pods/exec (objectRef.subresource: exec) | Qualcuno ha aperto una shell all’interno di un container in esecuzione |
| create di un ClusterRoleBinding a cluster-admin | Escalation dei privilegi a controllo totale |
| get o list su segreti da un’identità insolita | Raccolta delle credenziali |
| Pod creati con privilegi, hostPath o hostNetwork | Un passo verso la fuga sul nodo |
| user.username: system:anonymous con una risposta 2xx | Accesso anonimo che non dovrebbe funzionare |
| Esplosioni di 403 da un account di servizio | Un token rubato che verifica i suoi permessi |
Carica, igienizza e rivedi in LogTotal
- Carica. Apri logtotal.com e trascina il file .jsonl.
- Igienizza. [what gets masked: usernames, service account names, source IPs, namespaces, object names]. Look it over before you continue.
- Rivedere.
Quando va storto
| Sintomo | Probabile causa | Fix |
|---|---|---|
| Nessun file di audit sul piano di controllo | Il server API non ha configurato una politica di audit | Previsto; configurala per il futuro |
| Gruppo di log EKS o stream di audit mancanti | Il tipo di log del piano di controllo “audit” non è abilitato | Abilitalo per il futuro |
| Ogni linea è una lunga stringa scappata | Involucro CloudWatch | Disimballa con fromjson, come sopra |
| Puoi vedere chi ha modificato un pod, ma non come | La politica è a livello Metadata | Alza il livello per le risorse sensibili |
| Nessuna lettura di segreti nei dati AKS | kube-audit-admin esclude get e list | Raccogli kube-audit se ne hai bisogno |
FAQ
Non bastano i log dei container?
No. I log dei container mostrano ciò che un’applicazione ha stampato. Il log di audit mostra ciò che persone e account di servizio hanno fatto al cluster. Domande diverse, log diversi.
Posso leggere il file di audit su un cluster gestito?
No. Su EKS, AKS e GKE, non hai accesso ai nodi del piano di controllo. Il servizio di logging del provider è l’unico percorso.
