Criteri di audit

Questo documento descrive la policy di audit logging in Google Kubernetes Engine (GKE). Questo documento presuppone che tu conosca quanto segue:

GKE acquisisce e registra gli eventi nel tuo cluster e diversi fattori influenzano le informazioni registrate, la posizione in cui vengono archiviate e le policy che influenzano ciò che visualizzi negli audit log.

Questo documento è rivolto agli esperti di sicurezza che vogliono ottenere insight sulle attività che si verificano nei cluster per monitorare le minacce alla sicurezza, monitorare le modifiche e risolvere i problemi. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Per scoprire come abilitare e visualizzare i diversi tipi di audit log e per informazioni sulle autorizzazioni IAM richieste, consulta Informazioni sull'audit logging di GKE.

Panoramica delle policy di audit

In un cluster GKE, il server API Kubernetes scrive le voci degli audit log in un backend gestito da GKE. Quando GKE riceve le voci di log dal server API Kubernetes, le scrive nel log delle attività di amministrazione e nel log di accesso ai dati del tuo progetto.

Esistono due policy che influiscono su ciò che vedi negli audit log del tuo progetto:

  • La policy di audit di Kubernetes definisce le regole per gli eventi registrati come voci di log. Specifica inoltre quali dati devono includere le voci di log.

  • La policy di audit di GKE determina quali voci vengono scritte nel log delle attività di amministrazione e quali nel log di accesso ai dati.

Gli audit log scritti nel log di accesso ai dati dipendono dalla configurazione degli audit log. I log di accesso ai dati utilizzano i prezzi di Google Cloud Observability. I log delle attività di amministrazione sono offerti senza costi aggiuntivi. GKE supporta i seguenti tipi di log di accesso ai dati.

  • ADMIN_READ: operazioni che leggono i metadati sulle risorse Kubernetes, ad esempio l'elenco dei pod.
  • DATA_READ: operazioni che leggono i dati nelle risorse Kubernetes, ad esempio la lettura dei log di un pod.
  • DATA_WRITE: operazioni che scrivono dati nelle risorse Kubernetes, ad esempio l'aggiornamento dello stato dei pod.

Per saperne di più, consulta Configura i log di controllo dell'accesso ai dati.

Policy di audit di Kubernetes

Il server API Kubernetes segue una policy specificata nel flag --audit-policy-file del comando kube-apiserver.

Quando GKE avvia il server API Kubernetes, fornisce un file della policy di audit impostando il valore del flag --audit-policy-file. Nel repository Kubernetes open source, puoi visualizzare lo script configure-helper.sh, che genera il file della policy di controllo. Puoi visualizzare la maggior parte del file della policy di controllo guardando direttamente lo script.

Eventi e fasi

Quando una persona o un componente invia una richiesta al server API Kubernetes, la richiesta passa attraverso una o più fasi:

Fase Descrizione
RequestReceived Il gestore dell'audit ha ricevuto la richiesta.
ResponseStarted Le intestazioni della risposta sono state inviate, ma il corpo della risposta non è stato inviato.
ResponseComplete Il corpo della risposta è stato completato e non verranno inviati altri byte.
Panic Si è verificato un errore interno del server e la richiesta non è stata completata.

Ogni fase di una richiesta genera un evento, che viene elaborato in base a una policy. La policy specifica se l'evento deve essere registrato come voce di log e, in caso affermativo, quali dati devono essere inclusi nella voce di log.

Livelli di audit

Il file delle policy di audit di Kubernetes contiene un elenco di regole. Nel file della policy, la prima regola che corrisponde a un evento imposta il livello di controllo per l'evento.

Una regola può specificare uno dei seguenti livelli di controllo:

Livello Descrizione
Nessuno Non creare una voce di log per l'evento.
Metadati Crea una voce di log. Includi i metadati, ma non il corpo della richiesta o della risposta.
Richiesta Crea una voce di log. Includi i metadati e il corpo della richiesta, ma non il corpo della risposta.
RequestResponse Crea una voce di log. Includi i metadati, il corpo della richiesta e il corpo della risposta.

Ecco un esempio di regola. Se un evento corrisponde alla regola, il server API Kubernetes crea una voce di log a livello di Request.

- level: Request
  userGroups: ["system:nodes"]
  verbs: ["update","patch"]
  resources:
    - group: "" # core
      resources: ["nodes/status", "pods/status"]
  omitStages:
    - "RequestReceived"

Un evento corrisponde alla regola se tutte le seguenti condizioni sono vere:

  • L'evento non corrisponde a nessuna regola precedente nel file delle policy.
  • L'identità che effettua la chiamata si trova nel gruppo di utenti system:nodes.
  • La chiamata è una richiesta update o patch.
  • La richiesta riguarda una risorsa nodes/status o una risorsa pods/status.
  • L'evento non è per la fase RequestReceived della chiamata.

Policy di audit di GKE

Quando GKE riceve voci di log dal server API Kubernetes, applica la propria policy per determinare quali voci vengono scritte nel Log delle attività di amministrazione del progetto e quali nel log Accesso ai dati del progetto.

In generale, GKE applica le seguenti regole alle voci di log provenienti dal server API Kubernetes:

  • Le voci che rappresentano le richieste create, delete e update vengono inserite nel log delle attività di amministrazione.

  • Le voci che rappresentano le richieste get, list e updateStatus vengono inserite nel log di accesso ai dati.

Per informazioni sui prezzi e sui tipi di log abilitati per impostazione predefinita, consulta Dettagli di Logging.

File della policy di audit di Kubernetes per i cluster GKE

Per i cluster GKE, il file della policy di controllo di Kubernetes inizia con regole che specificano che determinati eventi non devono essere registrati. Ad esempio, questa regola indica che qualsiasi richiesta get di kubelet su una risorsa nodes o una risorsa nodes/status non deve essere registrata. Ricorda che un livello None indica che non deve essere registrato alcun evento corrispondente:

- level: None
  users: ["kubelet"] # legacy kubelet identity
  verbs: ["get"]
  resources:
    - group: "" # core
    resources: ["nodes", "nodes/status"]

Dopo l'elenco delle regole level: None, il file delle policy contiene un elenco di regole che rappresentano casi speciali. Ad esempio, ecco una regola per un caso speciale che indica di registrare determinate richieste a livello Metadata:

- level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"

Un evento corrisponde alla regola se tutte le seguenti condizioni sono vere:

  • L'evento non corrisponde a nessuna regola precedente nel file delle policy.
  • La richiesta riguarda una risorsa di tipo secrets, configmaps o tokenreviews.
  • L'evento non è per la fase RequestReceived della chiamata.

Dopo l'elenco delle regole per i casi speciali, il file delle policy contiene alcune regole generali. Per visualizzare le regole generali nello script, devi sostituire il valore di known_apis con ${known_apis}. Dopo la sostituzione, ottieni una regola come questa:

- level: Request
  verbs: ["get", "list", "watch"]
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

La regola si applica agli eventi che non corrispondono a nessuna regola precedente nel file della policy e non si trovano nella fase RequestReceived. La regola prevede che le richieste get, list e watch su qualsiasi risorsa appartenente a uno dei gruppi elencati debbano essere registrate a livello Request.

La regola successiva nel file delle policy è la seguente:

- level: RequestResponse
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

La regola si applica agli eventi che non corrispondono a nessuna regola precedente nel file della policy e non si trovano nella fase RequestReceived. In particolare, la regola non si applica alle richieste di lettura: get, list e watch. La regola si applica invece alle richieste di scrittura come create, update e delete. La regola indica che le richieste di scrittura devono essere registrate a livello di RequestResponse.

Riepilogo della policy di audit di Kubernetes per i cluster GKE

Il seguente elenco riepiloga la policy di audit di Kubernetes per i cluster GKE:

  • In generale, le richieste di scrittura come create, update e delete vengono registrate a livello RequestResponse.

  • In generale, gli eventi get, list e watch vengono registrati a livello Metadata.

  • Alcuni eventi vengono trattati come casi speciali. Per un elenco definitivo delle richieste che vengono trattate come casi speciali, consulta lo script delle norme. I casi speciali includono:

    • Le richieste di aggiornamento e patch di kubelet, system:node-problem-detector o system:serviceaccount:kube-system:node-problem-detector su una risorsa nodes/status o una risorsa pods/status vengono registrate a livello di richiesta.

    • Le richieste di aggiornamento e patch da parte di qualsiasi identità nel gruppo system:nodes su una risorsa nodes/status o una risorsa pods/status vengono registrate a livello di richiesta.

    • Le richieste deletecollection di system:serviceaccount:kube-system:namespace-controller vengono registrate a livello di richiesta.

    • Le richieste su una risorsa secrets, una risorsa configmaps o una risorsa tokenreviews vengono registrate a livello di metadati.

  • Alcune richieste non vengono registrate affatto. Per un elenco definitivo delle richieste che non vengono registrate, consulta le regole level: None nello script della policy. Le seguenti richieste non vengono registrate:

    • Richieste di system:kube-proxy per controllare una risorsa endpoints, una risorsa services o una risorsa services/status.

    • Richieste GET di system:unsecured su una risorsa configmaps nello spazio dei nomi kube-system.

    • Richieste GET di kubelet su una risorsa nodes o una risorsa nodes/status.

    • Richieste GET da parte di qualsiasi identità nel gruppo system:nodes su una risorsa nodes o una risorsa nodes/status.

    • Ricevi e aggiorna le richieste di system:kube-controller-manager, system:kube-scheduler o system:serviceaccount:endpoint-controller su una risorsa endpoints nello spazio dei nomi kube-system.

    • Richieste GET di system:apiserver su una risorsa namespaces, una risorsa namespaces/status o una risorsa namespaces/finalize.

    • Richieste Get ed Elenco di system:kube-controller-manager su qualsiasi risorsa nel gruppo metrics.k8s.io.

    • Richieste agli URL che corrispondono a /healthz*, /version o /swagger*.

Passaggi successivi