Criteri di audit

In questa pagina viene descritto il criterio di audit logging per Google Kubernetes Engine (GKE). Per istruzioni su come abilitare e visualizzare i diversi tipi di audit log, come autorizzazioni IAM richieste, consulta Informazioni sugli audit log di GKE.

Prima di iniziare

Prima di leggere questa pagina, assicurati di acquisire familiarità con questi argomenti:

Panoramica

In un cluster GKE, il server API Kubernetes scrive le voci degli audit log in un backend gestito da GKE. Come GKE riceve le voci di log dal server API Kubernetes, li 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 nei log di controllo del progetto:

  • Il criterio di controllo di Kubernetes definisce le regole in base alle quali gli eventi vengono registrati le voci di log. e specifica i dati che devono essere inclusi nelle voci di log.

  • Il criterio di controllo 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 dal log di controllo configurazione. 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, come come 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, come come aggiornamento dello stato dei pod.

Per ulteriori informazioni, consulta la pagina Configurare i log di controllo di accesso ai dati.

Criterio di controllo di Kubernetes

Il server API Kubernetes segue un criterio specificato in --audit-policy-file flag di kube-apiserver .

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

Eventi e fasi

Quando una persona o un componente invia una richiesta al server dell'API Kubernetes, la richiesta passa attraverso uno o più livelli:

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 inviate.
ResponseComplete Il corpo della risposta è stato completato e non verranno inviati altri byte.
Panico 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 un regola. Il criterio 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 controllo

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

Una regola può specificare uno di questi 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 la richiesta o il corpo 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 del log. Includi i metadati, il corpo della richiesta e i corpo della risposta.

Ecco un esempio di regola. Se un evento corrisponde alla regola, il server dell'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 tutte le seguenti condizioni sono vere:

  • L'evento non corrisponde a nessuna regola precedente nel file dei criteri.
  • L'identità che effettua la chiamata è inclusa nel 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 è per la 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 il livello RequestResponse.

  • In generale, gli eventi get, list e watch vengono registrati all'indirizzo Metadata livello.

  • 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 in cui scriviamo, questi sono i casi speciali:

    • Richieste di aggiornamento e applicazione di patch entro il giorno kubelet, system:node-problem-detector, oppure system:serviceaccount:kube-system:node-problem-detector su un Risorsa nodes/status o pods/status risorsa vengono registrate a livello di richiesta.

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

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

    • Richieste su una risorsa secrets, una risorsa configmaps o una tokenreviews risorsa viene registrata 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 dei criteri. Al momento della stesura di questo documento, le richieste che non vengono registrate sono le seguenti:

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

    • Ricevi richieste da system:unsecured su una risorsa configmaps in kube-system.

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

    • Ricevi richieste da qualsiasi identità del gruppo system:nodes su una risorsa nodes o nodes/status.

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

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

    • Recupera ed elenca le richieste di system:kube-controller-manager su qualsiasi risorsa nel gruppo metrics.k8s.io.

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

Criterio di audit GKE

Quando GKE riceve voci di log dal server API Kubernetes, applica le proprie norme per determinare quali voci vengono scritte nel log Attività di amministrazione del progetto e quali nel log Accesso ai dati.

Per la maggior parte, GKE applica le seguenti regole alle voci di log provenienti dal server API Kubernetes:

  • Le voci che rappresentano richieste create, delete e update vengono inviate al tuo 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 su Logging.

Informazioni sul file del criterio 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. Per Ad esempio, questa regola indica che qualsiasi richiesta get di kubelet su un nodes o una risorsa nodes/status non deve essere registrata. Ricorda che un livello di 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 di level: None regole, il file dei criteri include un elenco di regole che sono casi speciali. Ad esempio, una regola relativa a un caso speciale dice di registrare 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 tutte le seguenti condizioni sono vere:

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

Dopo l'elenco delle regole per casi speciali, il file delle norme contiene alcune regole generali. Per vedere le regole generali nel script, devi sostituire il valore 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 del criterio e non si trovano nella fase RequestReceived. La regola dice che get, Richieste list e watch su qualsiasi risorsa appartenente a una delle risorse elencate i gruppi devono essere registrati a livello di Request.

La regola successiva nel file delle norme è 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 del criterio 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 dice che le richieste di scrittura debbano essere registrate a livello di RequestResponse.

Passaggi successivi