Auf dieser Seite wird die geteilte Verantwortung für die Sicherheit von Google undGoogle Cloud -Kunden erläutert. Für die Ausführung einer geschäftskritischen Anwendung in Google Kubernetes Engine (GKE) müssen mehrere Parteien unterschiedliche Verantwortlichkeiten übernehmen. Diese Seite ist zwar keine vollständige Liste, kann Ihnen aber helfen, Ihre Verantwortlichkeiten zu verstehen.
Dieses Dokument richtet sich an Sicherheitsexperten, die Richtlinien und Verfahren zum Schutz der Daten einer Organisation vor unbefugtem Zugriff definieren, verwalten und implementieren. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.
Härtung und Patchen des Betriebssystems der Knoten, z. B. Container-Optimized OS oder Ubuntu GKE stellt umgehend alle Patches für diese Images zur Verfügung. Wenn Sie das automatische Upgrade aktiviert haben oder eine Release-Version verwenden, werden diese Updates automatisch bereitgestellt. Dies ist die Basisebene des Containers. Sie ist nicht mit dem Betriebssystem identisch, das in den Containern ausgeführt wird.
Erstellen und Nutzen von Bedrohungserkennung für Container-spezifische Bedrohungen im Kernel mit Container Threat Detection (wird separat mit Security Command Center abgerechnet).
Kubernetes-Knotenkomponenten härten und patchen. Für alle von GKE verwalteten Komponenten wird beim Upgrade der GKE-Knotenversionen automatisch ein Upgrade ausgeführt. Dazu zählen:
Härten und Patchen der Steuerungsebene. Die Steuerungsebene umfasst die VM der Steuerungsebene, den API-Server, den Planer, den Controller-Manager, die Clusterzertifizierungsstelle, die Ausgabe und Rotation von TLS-Zertifikaten, Root-of-Trust-Schlüsselmaterial, CA-Rotation, Secret-Verschlüsselung, IAM-Authentifizierung und -Autorisierung, Audit-Logging-Konfiguration, etcd und verschiedene andere Controller. Alle Komponenten der Steuerungsebene werden auf von Google verwalteten Compute Engine-Instanzen ausgeführt. Diese Instanzen sind ein einzelner Mandant. Das bedeutet, dass jede Instanz die Steuerungsebene und ihre Komponenten für nur einen Kunden ausführt.
Bereitstellen von Google Cloud Integrationen für Connect, Identity and Access Management, Cloud-Audit-Logs, Google Cloud Observability, Cloud Key Management Service, Security Command Center und andere.
Beschränken und Protokollieren des administrativen Zugriffs von Google auf Kundencluster mit Access Transparency für vertragliche Supportzwecke.
Verantwortlichkeiten des Kunden
Verwalten der Arbeitslasten, einschließlich des Anwendungscodes, der Build-Dateien, Container-Images, Daten, der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC)/IAM und der Container und Pods, die Sie ausführen.
In den folgenden Situationen müssen Sie Ihre Cluster und Knotenpools manuell upgraden, um Sicherheitslücken innerhalb der Patching-Zeitpläne Ihrer Organisation zu beheben:
Automatische Upgrades werden aufgrund von Faktoren wie Wartungsrichtlinien verschoben.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)."]]
