Questa pagina spiega le responsabilità condivise in materia di sicurezza sia per Google che per i clienti diGoogle Cloud . L'esecuzione di un'applicazione fondamentale per l'attività su Google Kubernetes Engine (GKE) richiede
che più parti abbiano responsabilità diverse. Sebbene questa pagina non sia un elenco
esaustivo, questo documento può aiutarti a comprendere le tue responsabilità.
Questo documento è destinato agli
esperti di sicurezza che definiscono, gestiscono e implementano policy e procedure
per proteggere i dati di un'organizzazione da accessi non autorizzati. Per scoprire di più sui
ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta
Ruoli e attività comuni degli utenti GKE. Google Cloud
Rafforzamento
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 sottostante
il container, non è lo stesso del sistema operativo in esecuzione nei
container.
Creazione e gestione del rilevamento delle minacce specifiche per i container nel kernel con Container Threat Detection (prezzo separato con Security Command Center).
Rafforzamento e
applicazione di patch
ai componenti dei nodi Kubernetes. Tutti i componenti gestiti di GKE vengono aggiornati
automaticamente quando esegui l'upgrade delle versioni dei nodi GKE. Ad esempio:
Rafforzamento e
applicazione di patch
al control plane. Il control plane include la VM del control plane, l'API server, lo scheduler, il gestore del controller, la CA del cluster, l'emissione e la rotazione dei certificati TLS, il materiale della chiave root-of-trust, l'autenticatore e l'autorizzatore IAM, la configurazione della registrazione degli audit, etcd e vari altri controller. Tutti i componenti del piano di controllo vengono eseguiti su istanze di 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.
Fornisci Google Cloud integrazioni per Connect,
Identity and Access Management, Cloud Audit Logs, Google Cloud Observability,
Cloud Key Management Service, Security Command Center e altri.
Limita e registra l'accesso amministrativo di Google ai cluster dei clienti per
scopi di assistenza contrattuale con
Access Transparency.
Responsabilità del cliente
Gestisci i tuoi carichi di lavoro, inclusi il codice dell'applicazione, i file di build,
le immagini dei container, i dati, i criteri di controllo dell'accesso basato sui ruoli (RBAC)/IAM
e i container e i pod in esecuzione.
Nelle seguenti situazioni, esegui l'upgrade manuale 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 quali le policy di manutenzione.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-01 UTC."],[],[],null,["[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page explains the shared security responsibilities for both Google and\nGoogle Cloud customers. Running a business-critical application on Google Kubernetes Engine (GKE) requires\nmultiple parties to have different responsibilities. Although this page is not an exhaustive\nlist, this document can help you understand your responsibilities.\n\nThis document is for Security specialists\nwho define, govern and implement policies and procedures\nto protect an organization's data from unauthorized access. To learn more about\ncommon roles and example tasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nGoogle's responsibilities\n\n- Protecting the underlying infrastructure, including hardware, firmware, kernel, OS, storage, network, and more. This includes [encrypting data at rest by default](/security/encryption-at-rest/default-encryption), providing [additional customer-managed disk encryption](/kubernetes-engine/docs/how-to/using-cmek), [encrypting data in transit](/security/encryption-in-transit), using [custom-designed hardware](/docs/security/titan-hardware-chip), laying [private network cables](/about/locations#network-tab), protecting data centers from physical access, protecting the bootloader and kernel against modification using [Shielded Nodes](/kubernetes-engine/docs/how-to/shielded-gke-nodes), and following secure software development practices.\n- [Hardening](/container-optimized-os/docs/concepts/security) and [patching](/kubernetes-engine/docs/resources/security-patching) the nodes' operating system, such as Container-Optimized OS or Ubuntu. GKE promptly makes any patches to these images available. If you have auto-upgrade enabled, or are using a [release channel](/kubernetes-engine/docs/concepts/release-channels), these updates are automatically deployed. This is the OS layer underneath your container---it's not the same as the operating system running in your containers.\n- Building and operating threat detection for container-specific threats into the kernel with [Container Threat Detection](/security-command-center/docs/concepts-container-threat-detection-overview) (priced separately with Security Command Center).\n- Hardening and [patching](/kubernetes-engine/docs/resources/security-patching) Kubernetes node components. All GKE managed components are upgraded automatically when you upgrade GKE node versions. This includes:\n - [vTPM-backed trusted bootstrap mechanism for issuing kubelet TLS certificates](/kubernetes-engine/docs/how-to/shielded-gke-nodes) and auto-rotation of the certificates\n - Hardened kubelet configuration [following CIS benchmarks](/kubernetes-engine/docs/concepts/cis-benchmarks)\n - GKE metadata server for [Workload identity](/kubernetes-engine/docs/how-to/workload-identity)\n - GKE's native [Container Network Interface plugin and Calico for NetworkPolicy](/kubernetes-engine/docs/concepts/network-overview)\n - GKE Kubernetes storage integrations such as the [CSI driver](/kubernetes-engine/docs/how-to/persistent-volumes/gce-pd-csi-driver)\n - GKE [logging and monitoring agents](/stackdriver/docs/solutions/gke)\n- Hardening and [patching](/kubernetes-engine/docs/resources/security-patching) the control plane. The control plane includes the control plane VM, API server, scheduler, controller manager, [cluster CA, TLS certificate issuance and rotation, root-of-trust key material](/kubernetes-engine/docs/concepts/cluster-trust), IAM authenticator and authorizer, audit logging configuration, etcd, and various other controllers. All of your control plane components run on Google-operated Compute Engine instances. These instances are single tenant, meaning each instance runs the control plane and its components for only one customer.\n- Provide Google Cloud integrations for Connect, Identity and Access Management, Cloud Audit Logs, Google Cloud Observability, Cloud Key Management Service, Security Command Center, and others.\n- Restrict and log Google administrative access to customer clusters for contractual support purposes with [Access Transparency](/access-transparency).\n\nCustomer's responsibilities\n\n- Maintain your workloads, including your application code, build files, container images, data, Role-based access control (RBAC)/IAM policy, and containers and pods that you are running.\n- [Rotate your clusters credentials](/kubernetes-engine/docs/how-to/credential-rotation#overview).\n- Keep Standard node pools enrolled in [automatic upgrades](/kubernetes-engine/upgrades#automatic_node_upgrades).\n- In the following situations, manually upgrade your clusters and node pools to remediate vulnerabilities within your organization's patching timelines:\n - Auto-upgrades are postponed because of factors like maintenance policies.\n - You need to apply a patch before it becomes available in your selected release channel. For more information, see [Run patch versions from a newer channel](/kubernetes-engine/docs/concepts/release-channels#newer-patch-versions).\n- Monitor the cluster and applications and respond to any alerts and incidents using technologies such as the [security posture dashboard](/kubernetes-engine/docs/concepts/about-security-posture-dashboard) and [Google Cloud Observability](/stackdriver/docs).\n- Provide Google with environmental details when requested for troubleshooting purposes.\n- Ensure Logging and Monitoring are enabled on clusters. *Without logs, support is available on a best-effort\n basis*.\n\nWhat's next\n\n- Read the GKE [Security overview](/kubernetes-engine/docs/concepts/security-overview)."]]