Criteri di audit

Questa pagina descrive i criteri di audit logging per Google Kubernetes Engine (GKE). Per istruzioni su come abilitare e visualizzare i diversi tipi di audit log, nonché le autorizzazioni IAM richieste, consulta Informazioni sull'audit logging di GKE.

Prima di iniziare

Prima di leggere questo argomento, dovresti acquisire familiarità con il materiale su questi argomenti:

Panoramica

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 criteri che influiscono su ciò che vedi negli audit log del progetto:

  • Il criterio di controllo di Kubernetes definisce le regole per cui gli eventi vengono registrati come voci di log. Specifica inoltre quali dati devono essere inclusi nelle voci di log.

  • Il criterio di controllo di GKE determina quali voci vengono scritte nel log delle attività di amministrazione e quali nel log degli accessi ai dati.

Gli audit log scritti nel log di accesso ai dati dipendono dalla configurazione degli audit log. I log degli accessi ai dati utilizzano i prezzi di Google Cloud Observability. I log delle attività di amministrazione sono disponibili 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 per un pod.
  • DATA_WRITE: operazioni che scrivono dati nelle risorse Kubernetes, come l'aggiornamento dello stato del pod.

Per ulteriori informazioni, consulta Configurare gli audit log di accesso ai dati.

Criterio di controllo di Kubernetes

Il server API Kubernetes segue un criterio specificato nel flag --audit-policy-file del comando kube-apiserver.

All'avvio del server API Kubernetes, GKE fornisce un file dei criteri di audit impostando il valore del flag --audit-policy-file. Nel repository Kubernetes open source, puoi vedere lo script configure-helper.sh, che genera il file del criterio di audit. La maggior parte del file dei criteri di audit è visibile direttamente nello 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.
Panico Si è verificato un errore interno del server, pertanto la richiesta non è stata completata.

Ogni fase di una richiesta genera un evento che viene elaborato in base a un criterio. Il criterio consente di specificare se l'evento deve essere registrato come voce di log e, in tal caso, quali dati devono essere inclusi nella voce di log.

Livelli di controllo

Il file dei criteri di controllo di Kubernetes contiene un elenco di regole. Nel file dei criteri, la prima regola corrispondente a un evento imposta il livello di controllo per l'evento.

Con una regola è possibile specificare uno dei seguenti livelli di controllo:

Livello Descrizione
Nessuna 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 includere il corpo della risposta.
RequestResponse Crea una voce di log. Includi i metadati, il corpo della richiesta e il corpo della risposta.

Di seguito è riportato un esempio di regola. Se un evento corrisponde alla regola, il server API Kubernetes crea una voce di log a livello 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 si verificano tutte le seguenti condizioni:

  • L'evento non corrisponde a nessuna regola precedente nel file dei criteri.
  • L'identità che effettua la chiamata fa parte del gruppo di utenti system:nodes.
  • La chiamata è una richiesta update o patch.
  • La richiesta è su una risorsa nodes/status o pods/status.
  • L'evento non è destinato alla fase RequestReceived della chiamata.

Riepilogo del criterio di controllo di Kubernetes per i cluster GKE

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

  • In generale, gli eventi get, list e watch vengono registrati a livello di 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 al momento della stesura di questo documento, di seguito sono riportati i casi speciali:

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

    • Le richieste di aggiornamento e applicazione di patch di qualsiasi identità nel gruppo system:nodes su una risorsa nodes/status o 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, configmaps o tokenreviews vengono registrate a livello di metadati.

  • Alcune richieste non vengono registrate. Per un elenco definitivo delle richieste non registrate, consulta le regole level: None nello script del criterio. Al momento della stesura di questo documento, queste sono le richieste che non vengono registrate:

    • Richieste effettuate da system:kube-proxy per visualizzare una risorsa endpoints, una risorsa services o una risorsa services/status.

    • Ricevi richieste da system:unsecured su una risorsa configmaps nello spazio dei nomi kube-system.

    • Ricevi richieste da kubelet su una risorsa nodes o nodes/status.

    • Ottieni richieste in base a qualsiasi identità nel gruppo system:nodes su una risorsa nodes o nodes/status.

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

    • Ricevi richieste da system:apiserver su una risorsa namespaces, namespaces/status o namespaces/finalize.

    • Recupera ed elenca le richieste in base a system:kube-controller-manager su qualsiasi risorsa del gruppo metrics.k8s.io.

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

Criterio di controllo GKE

Quando GKE riceve le voci di log dal server API Kubernetes, applica i propri criteri per determinare quali voci vengono scritte nel log dell'Log delle attività di amministrazione del progetto e quali vengono scritte nel log di accesso ai dati del progetto.

GKE applica in gran parte le seguenti regole alle voci di log provenienti dal server API Kubernetes:

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

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

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

Informazioni sul file dei criteri di controllo di Kubernetes

Per i cluster GKE, il file dei criteri 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 effettuata da kubelet su una risorsa nodes o nodes/status non deve essere registrata. Ricorda che un livello None significa che qualsiasi evento corrispondente non deve essere registrato:

- 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 dei criteri contiene un elenco di regole relative a casi speciali. Ad esempio, ecco una regola per i casi speciali indica di registrare determinate richieste a livello di Metadata:

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

Un evento corrisponde alla regola se si verificano tutte le seguenti condizioni:

  • L'evento non corrisponde a nessuna regola precedente nel file dei criteri.
  • La richiesta è relativa a una risorsa di tipo secrets, configmaps o tokenreviews.
  • L'evento non è destinato alla fase RequestReceived della chiamata.

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

- 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 dei criteri e non si trovano nella fase RequestReceived. La regola indica che le richieste get, list e watch su qualsiasi risorsa che appartiene a uno dei gruppi elencati devono essere registrate a livello Request.

La regola successiva nel file di criteri è simile alla 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 dei criteri 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 a richieste di scrittura come create, update e delete. La regola indica che le richieste di scrittura devono essere registrate a livello RequestResponse.

Passaggi successivi