Questo documento spiega le responsabilità di sicurezza condivise sia per Google che per Google Cloud i clienti. L'esecuzione di un'applicazione mission critical su Google Kubernetes Engine (GKE) richiede che più parti abbiano responsabilità diverse. Sebbene questo documento non sia un elenco esaustivo, può aiutarti a comprendere le tue responsabilità.
Questo documento è destinato agli specialisti della sicurezza che definiscono, regolano e implementano policy e procedure per proteggere i dati di un'organizzazione da accessi non autorizzati. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti GKE.
Responsabilità di Google
- Protezione dell'infrastruttura sottostante, inclusi hardware, firmware, kernel, sistema operativo, spazio di archiviazione, rete e altro ancora. Ciò include la crittografia dei dati at-rest per impostazione predefinita, la fornitura di una crittografia del disco gestita dal cliente aggiuntiva, la crittografia dei dati in transito, l'utilizzo di hardware progettato su misura, la posa di cavi di rete privata, la protezione dei data center dall'accesso fisico, la protezione del bootloader e del kernel da modifiche tramite i nodi schermati, e l'adozione di pratiche di sviluppo software sicure.
- Protezione e applicazione di patch al sistema operativo dei nodi, ad esempio Container-Optimized OS o Ubuntu. GKE rende immediatamente disponibili le patch per queste immagini. Se hai attivato l'upgrade automatico o utilizzi un canale di rilascio, questi aggiornamenti vengono implementati automaticamente. Questo è il livello del sistema operativo sotto il container, non è lo stesso del sistema operativo in esecuzione nei container.
- Creazione e gestione del rilevamento delle minacce per le minacce specifiche dei container nel kernel con Container Threat Detection (prezzo separato con Security Command Center).
- Protezione e
applicazione di patch
ai componenti dei nodi Kubernetes. Tutti i componenti gestiti da GKE vengono sottoposti ad upgrade automatico quando esegui l'upgrade delle versioni dei nodi GKE. Sono inclusi:
- Meccanismo di bootstrap attendibile basato su vTPM per l'emissione di certificati TLS kubelet e la rotazione automatica dei certificati
- Configurazione kubelet protetta in base ai benchmark CIS
- Server metadati GKE per Workload Identity
- Plug-in Container Network Interface nativo di GKE e Calico per NetworkPolicy
- Integrazioni di archiviazione Kubernetes GKE, come il driver CSI
- Agenti di logging e monitoraggio GKE
- Protezione e applicazione di patch al piano di controllo. Il piano di controllo include la VM del piano di controllo, il server API, lo scheduler, il gestore dei controller, la CA del cluster, l'emissione e la rotazione dei certificati TLS, il materiale delle chiavi root-of-trust, l'autenticatore e l'autorizzatore IAM, la configurazione dei log di audit , etcd e vari altri controller. Tutti i componenti del piano di controllo vengono eseguiti su istanze Compute Engine gestite da Google. Queste istanze sono single-tenant, il che significa che ogni istanza esegue il piano di controllo e i relativi componenti per un solo cliente.
- Fornire Google Cloud integrazioni per Connect, Identity and Access Management, Cloud Audit Logs, Google Cloud Observability, Cloud Key Management Service, Security Command Center e altri.
- Limitare e registrare l'accesso amministrativo di Google ai cluster dei clienti per scopi di assistenza contrattuale con Access Transparency.
Responsabilità del cliente
- Gestire i carichi di lavoro, inclusi il codice dell'applicazione, i file di build, le immagini container, i dati, la policy di controllo dell'accesso basato su ruoli (RBAC)/IAM e i container e i pod in esecuzione.
- Ruotare le credenziali dei cluster.
- Mantenere i pool di nodi Standard registrati per gli upgrade automatici.
- Nelle seguenti situazioni, esegui manualmente l'upgrade dei cluster e dei pool di nodi per correggere le vulnerabilità entro le tempistiche di applicazione delle patch della tua organizzazione:
- Gli upgrade automatici vengono posticipati a causa di fattori come le policy di manutenzione.
- Devi applicare una patch prima che diventi disponibile nel canale di rilascio selezionato. Per ulteriori informazioni, consulta Eseguire versioni delle patch da un canale più recente.
- Monitora il cluster e le applicazioni e rispondi ad avvisi e incidenti utilizzando tecnologie come la dashboard della security posture e Google Cloud Observability.
- Fornisci a Google i dettagli dell'ambiente quando richiesto per la risoluzione dei problemi.
- Assicurati che Logging e Monitoring siano abilitati sui cluster. Se non abiliti Logging e Monitoring e se il personale di assistenza non può accedere a questi log, l'assistenza è disponibile in base al principio del best effort.