이 페이지에서는 Google과Google Cloud 고객의 공유 보안 책임을 설명합니다. Google Kubernetes Engine(GKE)에서 비즈니스에 중요한 애플리케이션을 실행하려면 여러 당사자가 다양한 책임을 져야 합니다. 이 페이지에는 전체 목록은 아니지만 귀하의 책임을 이해하는 데 도움이 되는 내용이 나와 있습니다.
이 문서는 조직의 데이터를 무단 액세스로부터 보호하기 위한 정책과 절차를 정의, 제어, 구현하는 보안 전문가를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE Enterprise 사용자 역할 및 태스크를 참조하세요.
Container-Optimized OS 또는 Ubuntu와 같은 노드 운영체제 강화 및 패치. GKE에서 이러한 사용 가능한 이미지에 대한 모든 패치를 즉시 제공합니다. 자동 업그레이드를 사용 설정하거나 출시 채널을 사용하는 경우 이러한 업데이트가 자동으로 배포됩니다. 이는 컨테이너의 기본 OS 레이어이며 컨테이너에서 실행되는 운영체제와는 다릅니다.
컨트롤 플레인 강화 및 패치. 컨트롤 플레인에는 컨트롤 플레인 VM, API 서버, 스케줄러, 컨트롤러 관리자, 클러스터 CA, TLS 인증서 발급 및 순환, 신뢰할 수 있는 루트 키 자료, IAM 인증자 및 승인자, 감사 로깅 구성, etcd, 기타 다양한 컨트롤러가 포함됩니다. 모든 컨트롤 플레인 구성요소는 Google에서 운영하는 Compute Engine 인스턴스에서 실행됩니다. 이러한 인스턴스는 단일 테넌트입니다. 즉, 각 인스턴스는 한 고객을 위해서만 컨트롤 플레인과 구성요소를 실행합니다.
Connect, Identity and Access Management, Cloud 감사 로그, Google Cloud Observability, Cloud Key Management Service, Security Command Center 등의 Google Cloud 통합을 제공합니다.
계약 상의 지원을 목적으로 액세스 투명성을 통해 Google이 고객 클러스터에 대한 관리 액세스를 제한하고 로깅합니다.
고객의 책임
애플리케이션 코드, 빌드 파일, 컨테이너 이미지, 데이터, 역할 기반 액세스 제어(RBAC)/IAM 정책, 실행 중인 컨테이너 및 pod 등 워크로드를 유지보수합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-06-25(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)."]]
