Questa pagina spiega come attivare i log di controllo del sistema operativo dettagliati sui nodi Google Kubernetes Engine che eseguono Container-Optimized OS. Questa pagina spiega anche come configurare un agente di logging fluent-bit per inviare i log a Cloud Logging. L'attivazione della registrazione di auditd di Linux non è supportata nei cluster GKE Autopilot, perché Google gestisce i nodi e le macchine virtuali (VM) sottostanti.
L'audit logging del sistema operativo è diverso da Cloud Audit Logs e Kubernetes Audit Logs.
Panoramica
I log del sistema operativo sui nodi forniscono informazioni preziose sullo stato del cluster e dei carichi di lavoro, ad esempio messaggi di errore, tentativi di accesso ed esecuzioni di binari. Puoi utilizzare queste informazioni per eseguire il debug dei problemi o esaminare gli incidenti di sicurezza.
Per raccogliere i log da ogni nodo di un cluster, utilizza un
DaemonSet
che esegue esattamente un pod su ogni nodo del cluster in cui il DaemonSet è idoneo
a essere pianificato. Questo pod configura il daemon di logging auditd
sull'host e configura l'agente di logging in modo da inviare i log a Logging o a qualsiasi altro servizio di importazione dei log.
Per definizione, i controlli vengono eseguiti dopo un evento e sono una misura di sicurezza post-mortem. I log di auditd da soli probabilmente non sono sufficienti per eseguire la forensistica sul cluster. Valuta come utilizzare al meglio i log di auditd nell'ambito della tua strategia di sicurezza complessiva.
Limitazioni
I meccanismi di registrazione descritti in questa pagina funzionano solo sui nodi che eseguono un Container-Optimized OS nei cluster GKE Standard.
Come funziona il DaemonSet di logging
Questa sezione descrive il funzionamento del DaemonSet di logging di esempio in modo da poterlo configurare in base alle tue esigenze. Nella sezione successiva viene spiegato come eseguire il deployment del DaemonSet.
Il manifest di esempio definisce un DaemonSet, un ConfigMap e uno spazio dei nomi per contenerli.
Il DaemonSet esegue il deployment di un pod su ogni nodo del cluster. Il pod contiene due
container. Il primo è un contenitore init che avvia il servizio systemd cloud-audit-setup disponibile sui nodi Container-Optimized OS.
Il secondo contenitore,
cos-auditd-fluent-bit
, contiene un'istanza di
fluent-bit configurata per raccogliere gli audit log di Linux dal diario del nodo ed esportarli in
Cloud Logging.
Il DaemonSet di logging di esempio registra i seguenti eventi:
- Modifiche alla configurazione del sistema
auditd
- Controlli delle autorizzazioni AppArmor
- Esecuzioni di
execve()
,socket()
,setsockopt()
emmap()
- connessioni di rete
- Accessi utente
- Sessione SSH e tutti gli altri TTY (incluse le sessioni
kubectl exec -t
)
Configurazione del DaemonSet di logging
Configura il DaemonSet di logging utilizzando un ConfigMap,cos-auditd-fluent-bit-config
. L'esempio fornito invia gli audit log a logging, ma puoi configurarlo per inviare i log ad altre destinazioni.
Il volume dei log prodotti da auditd
può essere molto elevato e comportare costi aggiuntivi perché consuma risorse di sistema e invia più log rispetto alla configurazione di logging predefinita. Puoi configurare filtri per gestire il volume dei log:
- Puoi configurare filtri in
cos-auditd-fluent-bit-config
ConfigMap in modo che determinati dati non vengano registrati. Consulta la documentazione di fluent-bit per Grep, Modifica, Modificatore record e altri filtri. - Puoi anche configurare la registrazione per filtrare i log in entrata. Per maggiori dettagli, vedi Configurare e gestire i canali.
Esegui il deployment del DaemonSet di logging
Puoi utilizzare un cluster esistente o crearne uno nuovo.
Scarica i manifest di esempio:
curl https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/os-audit/cos-auditd-logging.yaml > cos-auditd-logging.yaml
Modifica i manifest di esempio in base alle tue esigenze. Consulta la sezione precedente per informazioni dettagliate sul funzionamento del DaemonSet.
Inizializza le variabili comuni:
export CLUSTER_NAME=CLUSTER_NAME export CLUSTER_LOCATION=COMPUTE_REGION
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del tuo cluster.COMPUTE_REGION
: la regione Compute Engine per il cluster. Per i cluster di zone, utilizza invece la zona.
Esegui il deployment dello spazio dei nomi, del daemonset e del ConfigMap di logging:
envsubst '$CLUSTER_NAME,$CLUSTER_LOCATION' < cos-auditd-logging.yaml \ | kubectl apply -f -
Verifica che i pod di logging siano stati avviati. Se hai definito uno spazio dei nomi diverso nei manifest, sostituisci cos-auditd con il nome dello spazio dei nomi che stai utilizzando.
kubectl get pods --namespace=cos-auditd
Se i pod sono in esecuzione, l'output è simile al seguente:
NAME READY STATUS RESTARTS AGE cos-auditd-logging-g5sbq 1/1 Running 0 27s cos-auditd-logging-l5p8m 1/1 Running 0 27s cos-auditd-logging-tgwz6 1/1 Running 0 27s
Viene implementato un pod su ciascun nodo del cluster, in questo caso il cluster ha tre nodi.
Ora puoi accedere agli audit log in Logging. In Esplora log, filtra i risultati utilizzando la seguente query:
LOG_ID("linux-auditd") resource.labels.cluster_name = "CLUSTER_NAME" resource.labels.location = "COMPUTE_REGION"
In alternativa, puoi utilizzare gcloud CLI (utilizza
--limit
perché il set di risultati può essere molto grande):gcloud logging read --limit=100 "LOG_ID("linux-auditd") AND resource.labels.cluster_name = "${CLUSTER_NAME}" AND resource.labels.location = "${CLUSTER_LOCATION}""
Esportazione dei log
Per scoprire come instradare i log alle destinazioni supportate, consulta Configurare e gestire i sink.
Esegui la pulizia
Per disattivare la registrazione di auditd
, elimina il DaemonSet di registrazione e riavvia i nodi. Una volta attivata, la configurazione di controllo viene bloccata e può essere modificata solo ricreando il nodo.
Elimina il DaemonSet, il ConfigMap e il relativo spazio dei nomi dal cluster:
kubectl delete -f cos-auditd-logging.yaml
Riavviare i nodi del cluster. Innanzitutto, ottieni il gruppo di istanze a cui appartengono:
instance_group=$(gcloud compute instance-groups managed list \ --format="value(name)" \ --filter=${CLUSTER_NAME})
Quindi ottieni le istanze stesse:
instances=$(gcloud compute instance-groups managed list-instances ${instance_group} \ --format="csv(instance)[no-heading][terminator=',']")
Infine, ricrea le istanze:
gcloud compute instance-groups managed recreate-instances ${instance_group} \ --instances=${instances}
Passaggi successivi
- Guarda Cloud Forensics 101 per iniziare a utilizzare la forensistica del cloud.
- Scopri di più sul logging di controllo di Kubernetes e sulle norme di controllo.
- Leggi la Panoramica della sicurezza di Kubernetes Engine.
- Scopri di più sugli audit log di Cloud.