Verifica le connessioni di Google al control plane GKE

Questa pagina descrive come verificare le connessioni effettuate dal personale di Google al control plane del cluster Google Kubernetes Engine (GKE) mettendo in correlazione i log di GKE con i log di Access Transparency.

I log di Access Transparency registrano le azioni intraprese dal personale di Google quando accede ai tuoi contenuti. Questa guida è destinata agli amministratori della sicurezza che vogliono una verifica aggiuntiva dei contenuti dei log di Access Transparency e delle approvazioni di Access Approval associate mettendo in correlazione con altre origini di logging di GKE. Questa verifica è completamente facoltativa e non è necessaria per proteggere il control plane.

Assicurati di conoscere i seguenti concetti:

Questa pagina descrive una parte di un insieme di funzionalità facoltative del control plane in GKE che ti consentono di eseguire attività come la verifica della security posture del control plane o la configurazione della crittografia e della firma delle credenziali nel control plane utilizzando le chiavi che gestisci. Per i dettagli, consulta Informazioni su GKE control plane authority.

Per impostazione predefinita, Cloud de Confiance applica varie misure di sicurezza al control plane gestito. Questa pagina descrive le funzionalità facoltative che ti offrono maggiore visibilità o controllo su control plane GKE.

Informazioni sull'accesso di Google alle istanze del control plane del cluster

Durante le sessioni di risoluzione dei problemi o per altri motivi aziendali giustificati, il personale di Google, come gli ingegneri di affidabilità del sito e i dipendenti dell'assistenza clienti Google Cloud, potrebbe aver bisogno dell'accesso amministrativo alle istanze Compute Engine che ospitano il control plane. A seconda del pacchetto di assistenza clienti e della configurazione, Access Transparency fornisce log di controllo dettagliati per questo accesso amministrativo. Access Approval ti consente di richiedere l'approvazione esplicita prima che il personale di Google possa accedere alle tue risorse. Per saperne di più sull'accesso amministrativo e sugli strumenti che puoi utilizzare per autorizzare l'accesso e registrare le modifiche, consulta Accesso amministrativo per i dipendenti di Google.

Log di accesso al control plane

Quando abiliti GKE control plane authority, GKE genera log di accesso al control plane che puoi utilizzare facoltativamente per fare riferimento incrociato agli audit log generati da Access Transparency e da Access Approval. GKE adds control plane access logs to the _Default bucket in Logging to record incoming network connections and specific SSH events in your control plane instances. Devi abilitare GKE control plane authority nel tuo progetto per generare i log di accesso al control plane per i tuoi cluster.

GKE genera i seguenti log di accesso per il control plane:

Il volume dei log di connessione del control plane dipende da fattori quali il numero di nodi nel cluster, il numero di istanze del control plane (i cluster regionali hanno più istanze del control plane rispetto ai cluster zonali) e la frequenza con cui i carichi di lavoro chiamano il server API Kubernetes. Il volume dei log SSH è ridotto e dipende dal numero di riavvii dei nodi.

Per verificare le connessioni al control plane, trova i log di accesso al control plane per il tuo cluster e abbinali agli audit log di Access Transparency e Access Approval. In questo modo puoi confermare che tutte le connessioni SSH alle istanze del control plane sono state il risultato dell'accesso amministrativo autorizzato da parte del personale di Google. Quando abiliti GKE control plane authority per il tuo cluster, tutto l'accesso SSH del personale di Google al tuo control plane è non interattivo, il che significa che ogni connessione SSH esegue un singolo comando che autorizzi. Per visualizzare i dettagli a livello di comando per l'accesso amministrativo, registrati ad Augmented Access Approval e Augmented Access Transparency. Per ulteriori informazioni sull'idoneità e sulla registrazione, contatta il tuo Cloud de Confiance by S3NS team dedicato all'account.

Prezzi

Si applicano le seguenti considerazioni sui prezzi:

  • I log di accesso al control plane sono soggetti a prezzi di Logging.
  • Access Transparency è incluso in abbonamenti specifici all'assistenza clienti. Per i dettagli, consulta i prezzi di Access Transparency.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

  • Abilita l'API Cloud Logging.

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre del ruolo IAM Amministratore utilizzo servizi (roles/serviceusage.serviceUsageAdmin), che contiene l'autorizzazione serviceusage.services.enable. Scopri come concedere i ruoli.

    Abilitare l'API

  • Abilita Access Transparency per la tua organizzazione. Per le istruzioni, consulta Abilitare Access Transparency.

  • Facoltativamente, abilita Access Approval per il tuo progetto e seleziona il servizio GKE. Per le istruzioni, consulta Esaminare e approvare le richieste di accesso utilizzando la chiave di firma gestita da Google.

  • Assicurati che il tuo ambiente sia idoneo all'utilizzo delle funzionalità di GKE control plane authority. Per attivare queste funzionalità, contatta il tuo Cloud de Confiance team di vendita.

Requisiti

I log di accesso al control plane richiedono la versione 1.31.1-gke.1846000 di GKE o versioni successive.

Ruoli e autorizzazioni richiesti

Per ottenere le autorizzazioni necessarie per abilitare la generazione dei log e per accedere ed elaborare i log, chiedi all'amministratore di concederti i seguenti ruoli IAM:

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Abilitare i log di accesso al control plane del cluster GKE

Puoi abilitare la generazione dei log di accesso al control plane per i cluster in modalità Autopilot e in modalità Standard abilitando il componente di logging corrispondente. Per saperne di più sui tipi di log del control plane, consulta Visualizzare i log di GKE.

I nomi dei componenti di logging supportati per i log di accesso al control plane sono i seguenti:

  • Log SSH del control plane: KCP_SSHD
  • Log di connessione del control plane: KCP_CONNECTION

Abilitare i log di accesso al control plane su un nuovo cluster

L'esempio seguente crea un cluster in modalità Autopilot con entrambi i tipi di log di accesso al control plane abilitati. Per abilitare un solo tipo di log di accesso al control plane, ometti il nome del componente corrispondente dal comando.

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,KCP_SSHD,KCP_CONNECTION

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del nuovo cluster.
  • LOCATION: la località in cui creare il cluster.

Per specificare i componenti di logging quando crei un cluster utilizzando l' API GKE, nel projects.locations.clusters.create metodo, imposta i valori corrispondenti nell' LoggingConfig oggetto della Cluster risorsa.

Abilitare i log di accesso al control plane su un cluster esistente

Per aggiornare la configurazione di logging di un cluster esistente in modo da abilitare i log di accesso al control plane, devi procedere nel seguente modo:

  1. Trova i componenti di logging esistenti utilizzati dal cluster.
  2. Identifica i valori corrispondenti da specificare nel flag --logging in gcloud CLI per mantenere abilitati questi componenti di logging.
  3. Aggiorna la configurazione di logging del cluster per abilitare i log di accesso al control plane insieme alla configurazione di logging esistente.

I valori specificati per il flag --logging nel comando gcloud container clusters update sono diversi dai valori visualizzati quando descrivi il cluster.

  1. Controlla la configurazione di logging esistente del cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=loggingConfig \
    --format='csv[delimiter=",",no-heading](componentConfig.enableComponents)'

    L'output è simile al seguente:

    SYSTEM_COMPONENTS,WORKLOADS,APISERVER,SCHEDULER,CONTROLLER_MANAGER

  2. Identifica i valori di gcloud CLI per il flag --logging che corrispondono alla configurazione del componente di logging dall'output del passaggio precedente. Per un elenco dei valori di gcloud CLI che corrispondono a componenti di logging specifici, consulta la tabella Log disponibili.

  3. Aggiorna la configurazione di logging con i log di accesso al control plane:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,EXISTING_LOGS,KCP_ACCESS_LOGS

    Sostituisci quanto segue:

    • EXISTING_LOGS: un elenco separato da virgole dei componenti di logging già utilizzati dal cluster. Assicurati di specificare i valori di gcloud CLI che corrispondono a questi componenti di logging, presi dalla tabella Log disponibili.

    • KCP_ACCESS_LOGS: un elenco separato da virgole dei tipi di log di accesso al control plane da abilitare per il cluster, come segue:

      • Per i log SSH del control plane, specifica KCP_SSHD.
      • Per i log di connessione del control plane, specifica KCP_CONNECTION.

Per specificare i componenti di logging quando aggiorni un cluster utilizzando l' API GKE, nel projects.locations.clusters.update metodo, imposta i valori dei componenti di logging esistenti e nuovi nell' LoggingConfig oggetto della ClusterUpdate risorsa.

Esempio di aggiornamento del cluster per abilitare i log di accesso al control plane

Considera un cluster che mostra la seguente configurazione di logging dopo aver eseguito il comando gcloud container clusters describe:

SYSTEM_COMPONENTS,WORKLOADS,APISERVER,SCHEDULER,CONTROLLER_MANAGER

Il seguente comando di aggiornamento del cluster abilita entrambi i tipi di log di accesso al control plane mantenendo la configurazione dei log esistente per questo cluster di esempio:

gcloud container clusters update example-cluster \
    --location=us-central1 \
    --logging=SYSTEM,WORKLOAD,API_SERVER,SCHEDULER,CONTROLLER_MANAGER,KCP_SSHD,KCP_CONNECTION

Fare riferimento incrociato ai log di accesso al control plane con i log di Access Transparency

Per verificare l'accesso al control plane per un cluster, recupera i log di connessione del control plane, i log SSH del control plane e i log di Access Transparency per quel cluster:

  1. Nella Cloud de Confiance console, apri la pagina Esplora log.

    Vai a Esplora log

  2. Per recuperare tutti i log di un cluster specifico, inclusi i log di accesso al control plane e i log di Access Transparency, esegui la seguente query:

    (logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-connection"
resource.labels.cluster_name="CLUSTER_NAME"
jsonPayload.connection.dest_port="22")
OR
(logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-sshd"
resource.labels.cluster_name="CLUSTER_NAME")
OR
(logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Faccess_transparency"
json_payload.accesses.methodName="GoogleInternal.SSH.Master"
json_payload.accesses.resourceName="//container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME")

L'output dovrebbe mostrare tutti i seguenti tipi di log per il tuo cluster:

  • Log di Access Transparency
  • Log di connessione del control plane
  • Log SSH per ogni sessione SSH

Eseguire i controlli di verifica

Il controllo di verifica principale consiste nel verificare se vengono visualizzati tutti i tipi di log per le connessioni SSH quando esegui la query di Logging nella sezione precedente. Ogni log di Access Transparency deve avere un log di connessione del control plane corrispondente e uno o più log SSH. Questi log riguardano le azioni eseguite dagli utenti nelle istanze del control plane, quindi il volume dei log dovrebbe essere ridotto.

Facoltativamente, puoi eseguire i seguenti controlli aggiuntivi dei contenuti dei log:

  1. Per ogni log SSH del control plane, controlla se esiste un log di Access Transparency in un intervallo di 15 minuti prima del timestamp del log SSH. Questo intervallo di tempo tiene conto della chiusura finale della sessione SSH che avviene diversi minuti dopo la registrazione della connessione iniziale da parte di Access Transparency.
  2. Per ogni log di connessione del control plane, controlla se esiste un log di Access Transparency in un intervallo di 5 minuti prima del timestamp del log di connessione del control plane.

  3. Se utilizzi Access Approval per il tuo cluster, controlla se ogni log di Access Transparency ha un campo accessApprovals corrispondente. Fai riferimento incrociato a questo campo con le richieste di Access Approval per il tuo cluster.

    Per ottenere le richieste di Access Approval per il tuo progetto, consulta Visualizzare le richieste di Access Approval storiche. Access Approval potrebbe essere soggetto a esclusioni.

  4. Facoltativamente, convalida la firma di Access Approval firmata associata al log di Access Transparency.

Dettagli dei log di accesso al control plane

Questa sezione fornisce dettagli ed esempi dei log di accesso al control plane generati da GKE quando il personale di Google si connette alle istanze del control plane.

Log di connessione del control plane

GKE aggiunge un log di connessione del control plane per ogni nuova connessione di rete in entrata a un'istanza del control plane. Questi log includono dettagli specifici come i seguenti:

  • Indirizzi IP e porte di origine e destinazione
  • Direzione e protocollo di connessione

Di seguito è riportato un esempio di log di connessione del control plane:

{
  insertId: "z1eq8wonio335a5h",
  jsonPayload: {
    instance: {
      vm_name: "gke-dee49f0d6fa34ce3a2ac-f513-d195-vm",
      zone: "us-central1-c"
    },
    cluster: {
      cluster_id: "CLUSTER_ID",
      cluster_urn: "//container.googleapis.com/projects/PROJECT_NUMBER/locations/us-central1-c/clusters/CLUSTER_NAME"
    },
    connection: {
      state: "NEW",
      src_ip: "192.0.2.100",
      src_port: 32774,
      dest_ip: "203.0.113.12",
      dest_port: 22,
      direction: "INGRESS"
      protocol: "TCP"
    },
  }
  logName: "projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-connection",
  receiveTimestamp: "2024-04-11T04:08:01.883070399Z",
  resource: {
    labels: {
      cluster_name: "CLUSTER_NAME",
      location: "us-central1-c",
      project_id: "PROJECT_ID"
    }
    type: "gke_cluster",
  }
  severity: "NOTICE",
  timestamp: "2024-04-11T04:07:59.019330Z"
}

I seguenti campi nella voce di log sono pertinenti per la verifica delle azioni di Google:

  • cluster.cluster_urn: l'identificatore di risorsa completo del cluster. Questo identificatore ha il formato //container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME, con le seguenti variabili:

    • PROJECT_NUMBER: il numero di progetto numerico del progetto dei cluster.
    • LOCATION: la Cloud de Confiance località del cluster.
    • CLUSTER_NAME: il nome del cluster.

  • connection: dettagli sul tentativo di connessione. Questo campo contiene le seguenti informazioni:

    • state: lo stato della connessione. Per le nuove connessioni, il valore è NEW.
    • src_ip: l'indirizzo IP dell'origine della connessione.
    • src_port: il numero di porta dell'origine della connessione.
    • dest_ip: l'indirizzo IP interno della VM del control plane.
    • dest_port: il numero di porta di destinazione.
    • direction: la direzione della connessione. Il valore è sempre INGRESS.
    • protocol: il protocollo IP, ad esempio TCP.

Log SSH del control plane

GKE aggiunge i log SSH del control plane per gli eventi relativi alle connessioni SSH alle istanze del control plane. GKE registra i seguenti eventi:

  • Chiave SSH accettata per un utente
  • Lo stato della sessione è cambiato da 0 a 1, il che indica che l'utente ha eseguito l'accesso correttamente
  • Sessione SSH aperta
  • Sessione SSH chiusa
  • Lo stato della sessione è cambiato da 1 a 0, il che indica che l'utente ha eseguito la disconnessione
  • Sessione SSH non riuscita

Ad esempio, il seguente log SSH del control plane riguarda l'apertura di una sessione SSH:

{
  insertId: "8llczemdulwbbwpa",
  jsonPayload: {
    instance: {
      vm_name: "gke-06cb920c609941c0a5ce-6840-40e9-vm",
      zone: "us-central1-c"
    },
    cluster: {
      cluster_id: "891e6d12889747748c1ac16ffcc6cb7c0a96450b36864eb680917c119fd801d0",
      cluster_urn: "//container.googleapis.com/projects/PROJECT_NUMBER/locations/us-central1/clusters/CLUSTER_NAME",
    },
    message: "pam_unix(sshd:session): session opened for user REDACTED by (uid=0)",
  },
  logName: "projects/PROJECT_ID/logs/container.googleapis.com%2Fkcp-ssh",
  receiveTimestamp: "2024-04-09T13:21:55.231436462Z"
  resource: {
    type: "gke_cluster",
    labels: {
      cluster_name: "CLUSTER_NAME",
      location: "us-central1",
      project_id: "PROJECT_ID"
    }
  },
  severity: "NOTICE",
  timestamp: "2024-04-09T13:21:50.742246Z"
}

I seguenti campi nella voce di log sono pertinenti per la verifica delle azioni di Google:

  • cluster.cluster_urn: l'identificatore di risorsa completo del cluster. Questo identificatore ha il formato //container.googleapis.com/projects/PROJECT_NUMBER/locations/LOCATION/clusters/CLUSTER_NAME, con le seguenti variabili:

    • PROJECT_NUMBER: il numero di progetto numerico del progetto del cluster.
    • LOCATION: la Cloud de Confiance località del cluster.
    • CLUSTER_NAME: il nome del cluster.

  • message: dettagli sulla connessione SSH.

Disabilitare i log di accesso al control plane

  1. Per visualizzare i tipi di log specifici utilizzati dal cluster, esegui il seguente comando:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=loggingConfig \
    --format='csv[delimiter=",",no-heading](componentConfig.enableComponents)'

    L'output è simile al seguente:

    SYSTEM_COMPONENTS,WORKLOADS,API_SERVER,SCHEDULER,CONTROLLER_MANAGER,KCP_SSHD,KCP_CONNECTION

  2. Per disabilitare i log di accesso al control plane per un cluster, esegui il seguente comando:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --logging=SYSTEM,WORKLOAD,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

Nel flag --logging, specifica i componenti di logging dall'output del comando precedente. Questo comando di esempio disabilita i log di accesso al control plane, ma mantiene abilitati gli altri log dei componenti del control plane.

Per disabilitare i componenti di logging utilizzando l'API GKE, imposta i valori corrispondenti nell'oggetto LoggingConfig della risorsa ClusterUpdate nel metodo projects.locations.clusters.update.

Passaggi successivi