Criteri di audit

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In questa pagina vengono descritti i criteri di audit logging per Google Kubernetes Engine (GKE).

Prima di iniziare

Prima di leggere questo argomento, dovresti conoscere il materiale di questi argomenti:

Panoramica

In un cluster GKE, il server API di Kubernetes scrive le voci dell'audit log in un backend gestito da GKE. Quando GKE riceve voci di log dal server API di Kubernetes, le scrive nei log Attività amministratore e Accesso ai dati del tuo progetto.

I criteri visualizzati nei log di controllo del tuo progetto sono due:

  • 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 sono 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 dell'audit log. I log di accesso ai dati utilizzano i prezzi della suite operativa di Google Cloud. 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 i dati nelle risorse Kubernetes, ad esempio l'aggiornamento dello stato dei pod.

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

Criterio di controllo Kubernetes

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

Quando GKE avvia il server API di Kubernetes, fornisce un file del criterio di controllo impostando il valore del flag --audit-policy-file. Nel repository open source di Kubernetes puoi vedere lo script configure-helper.sh, che genera il file del criterio di controllo. Puoi visualizzare la maggior parte del file dei criteri 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
Richiesta ricevuta Il gestore di controllo ha ricevuto la richiesta.
Risposta iniziata Le intestazioni della risposta sono state inviate, ma il corpo della risposta non è stato inviato.
Risposta completata 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 criterio. Il criterio specifica 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 di 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 il corpo della richiesta o del corpo della risposta.
Risorse richieste: Crea una voce di log. Includi i metadati e il corpo della richiesta, ma non includere il corpo della risposta.
Richiesta/risposta 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 soddisfatte:

  • L'evento non corrisponde ad alcuna regola precedente nel file di criteri.
  • L'identità che effettua la chiamata è inclusa nel gruppo di utenti system:nodes.
  • La chiamata è una richiesta update o una richiesta patch.
  • La richiesta riguarda una risorsa nodes/status o una risorsa pods/status.
  • L'evento non è per la fase RequestReceived della chiamata.

Riepilogo del criterio di controllo 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 sono considerati come casi speciali. Per un elenco definitivo di richieste trattate come casi speciali, consulta lo script delle norme. Al momento della stesura di questo articolo, si tratta di casi particolari:

    • 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 di una risorsa pods/status vengono registrate a livello di richiesta.

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

    • deletecollection richieste entro il giorno 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. Per un elenco definitivo delle richieste non registrate, consulta le regole level: None nello script dei criteri. Al momento della stesura di questo articolo, queste sono le richieste che non vengono registrate:

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

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

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

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

    • Ricevi e aggiorna le richieste da 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, una risorsa namespaces/status o una risorsa namespaces/finalize.

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

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

Criterio di controllo GKE

Quando GKE riceve voci di log dal server API di Kubernetes, applica il proprio criterio per determinare quali voci vengono scritte nel log Attività di amministrazione del progetto e quali vengono scritte nel log di accesso ai dati del tuo progetto.

Per la maggior parte, 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 registrate nel log delle attività di amministrazione.

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

Per informazioni sui prezzi e sui tipi di log attivati per impostazione predefinita, consulta i dettagli di logging.

Informazioni sul file dei criteri di controllo di Kubernetes

Per i cluster GKE, il file di 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 di kubelet su una risorsa nodes o una risorsa 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 di level: None regole, il file dei criteri presenta un elenco di regole che sono casi speciali. Ad esempio, ecco una regola per i casi speciali che chiede 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 tutte le seguenti condizioni sono soddisfatte:

  • L'evento non corrisponde ad alcuna regola precedente nel file di criteri.
  • La richiesta è su 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 di criteri presenta alcune regole generali. Per vedere le regole generali nello script, devi sostituire il valore di known_apis con ${known_apis}. Dopo la sostituzione, viene applicata una regola simile alla 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 del file di criteri e non sono nella fase RequestReceived. La regola indica che le richieste get, list e watch per qualsiasi risorsa che appartiene a uno dei gruppi elencati devono essere registrate a livello di Request.

La regola successiva nel file di criteri sarà 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 del file di criteri e non sono 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 di RequestResponse.

Passaggi successivi