Abilitare i log auditd di Linux sui nodi GKE

Questa pagina spiega come abilitare gli audit log dettagliati del sistema operativo sui nodi Google Kubernetes Engine che eseguono Container-Optimized OS. Questa pagina spiega anche come configurare un agente Logging fluent-bit per inviare i log a Cloud Logging. L'attivazione dei log dettagliati può fornire informazioni preziose sullo stato del cluster e dei carichi di lavoro, ad esempio messaggi di errore, tentativi di accesso ed esecuzioni di file binari. Puoi utilizzare queste informazioni per eseguire il debug dei problemi o esaminare gli incidenti di sicurezza.

L'attivazione del logging auditd di Linux non è supportata nei cluster GKE Autopilot, perché Google gestisce i nodi e le macchine virtuali (VM) sottostanti.

Questa pagina è destinata agli esperti di sicurezza che esaminano e analizzano i log di sicurezza. Utilizza queste informazioni per comprendere i requisiti e le limitazioni dei log dettagliati del sistema operativo e per guidare l'implementazione quando li attivi sui nodi GKE. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli utente e attività comuni di GKE.

Prima di leggere questa pagina, assicurati di avere familiarità con gli audit log del sistema operativo Linux.

L'audit logging del sistema operativo è diverso da Cloud Audit Logs e Kubernetes Audit Logs.

Panoramica

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 per la pianificazione. Questo pod configura il daemon di logging auditd sull'host e configura l'agente Logging per inviare i log a Logging o a qualsiasi altro servizio di inserimento dei log.

Per definizione, l'audit si verifica dopo un evento ed è una misura di sicurezza retrospettiva. I log di auditd da soli probabilmente non sono sufficienti per condurre analisi forensi sul tuo cluster. Valuta come utilizzare al meglio la registrazione auditd nell'ambito della tua strategia di sicurezza generale.

Limitazioni

I meccanismi di logging descritti in questa pagina funzionano solo sui nodi che eseguono Container-Optimized OS nei cluster GKE Standard.

Come funziona il DaemonSet di logging

Questa sezione descrive il funzionamento di example logging DaemonSet in modo che tu possa configurarlo in base alle tue esigenze. La sezione successiva spiega come eseguire il deployment del DaemonSet.

Il manifest di esempio definisce un DaemonSet, un ConfigMap e uno spazio dei nomi per contenerli.

DaemonSet esegue il deployment di un pod su ogni nodo del cluster. Il pod contiene due container. Il primo è un container init che avvia il servizio systemd cloud-audit-setup disponibile sui nodi Container-Optimized OS. Il secondo container, cos-auditd-fluent-bit, contiene un'istanza di fluent-bit configurata per raccogliere i log di controllo di Linux dal journal del nodo ed esportarli in Cloud Logging.

Il DaemonSet di logging di esempio registra i seguenti eventi:

  • auditd modifiche alla configurazione del sistema
  • Controlli delle autorizzazioni AppArmor
  • execve(), socket(), setsockopt() e mmap() esecuzioni
  • connessioni di rete
  • accessi utente
  • Sessione SSH e tutti gli altri TTY (incluse le sessioni kubectl exec -t)

Configura il 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 di log generati da auditd può essere molto elevato e potrebbe comportare costi aggiuntivi perché consuma risorse di sistema e invia più log rispetto alla configurazione di logging predefinita. Puoi configurare i filtri per gestire il volume di logging:

Esegui il deployment di DaemonSet di logging

  1. Puoi utilizzare un cluster già esistente o crearne uno nuovo.

  2. Scarica i manifest di esempio:

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/troubleshooting/os-audit/cos-auditd-logging.yaml > cos-auditd-logging.yaml

  3. Modifica i manifest di esempio in base alle tue esigenze. Per informazioni dettagliate sul funzionamento del DaemonSet, consulta la sezione precedente. Tieni presente che l'immagine fluent-bit utilizzata in questo manifest di esempio è solo a scopo dimostrativo. Come best practice, sostituisci l'immagine con un'immagine proveniente da una fonte controllata con digest SHA-256.

  4. 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 di Compute Engine per il cluster. Per i cluster a livello di zona, utilizza la zona.

  5. Esegui il deployment dello spazio dei nomi, del DaemonSet e di ConfigMap per la registrazione:

    envsubst '$CLUSTER_NAME,$CLUSTER_LOCATION' < cos-auditd-logging.yaml \
| kubectl apply -f -

  6. 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

    Un pod viene eseguito il deployment su ciascun nodo del cluster. In questo caso, il cluster ha tre nodi.

  7. 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}""

Esporta log

Per scoprire come instradare i log alle destinazioni supportate, consulta Configura e gestisci i sink.

Disattiva log

Per disattivare la registrazione di auditd sui nodi, elimina DaemonSet di registrazione e poi implementa cos-auditd-logging-disable DaemonSet per ripristinare le modifiche del servizio systemd su ogni nodo. Dopo aver eseguito il deployment di questo DaemonSet, non puoi attivare il logging di auditd, a meno che i nodi non vengano ricreati.

  1. Elimina il DaemonSet di logging originale e le risorse correlate:

    kubectl delete daemonset cos-auditd-logging -n cos-auditd
kubectl delete configmap fluent-bit-config -n cos-auditd
# The namespace will be deleted by the cleanup daemonset's namespace definition

  2. Applica il DaemonSet di pulizia cos-auditd-logging-disable:

    kubectl apply -f 'https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/troubleshooting/os-audit/cos-auditd-logging-disable.yaml'

  3. Verifica che i pod cleanup-auditd siano in esecuzione su tutti i nodi:

    kubectl get pods -n cos-auditd -l name=cleanup-auditd -w

    Attendi che tutti i pod mostrino Running.

  4. Dopo l'esecuzione dei pod di pulizia, verifica che non vengano generati nuovi log linux-auditd eseguendo le query dalla sezione Deployment del DaemonSet di logging. Ad esempio, puoi utilizzare il seguente comando gcloud CLI:

    gcloud logging read --limit=10 --freshness="5m" \
  "LOG_ID(\"linux-auditd\") AND \
  resource.labels.cluster_name = \"${CLUSTER_NAME}\" AND \
  resource.labels.location = \"${CLUSTER_LOCATION}\""

    Questo comando controlla i log degli ultimi cinque minuti. Se la pulizia è andata a buon fine, l'output è vuoto.

    Allo stesso modo, quando utilizzi Cloud Explorer con lo stesso filtro, non dovresti visualizzare nuove voci di log dopo l'ora di pulizia.

  5. Elimina il daemonset e lo spazio dei nomi di pulizia:

    kubectl delete -f cleanup-auditd-daemonset.yaml

    Questo comando eliminerà sia il DaemonSet che lo spazio dei nomi cos-auditd.

Passaggi successivi