컨트롤 플레인과 노드 간의 트래픽: 컨트롤 플레인은 컨테이너를 관리하기 위해 노드와 통신합니다. 컨트롤 플레인이 노드에 요청(예: kubectl logs)을 보내면 이 요청은 Konnectivity 프록시 터널을 통해 전송됩니다. 컨트롤 플레인이 전송하는 요청은 TLS로 인증 및 보호됩니다. 노드가 컨트롤 플레인에 요청을 보내면(예를 들어 kubelet에서 API 서버로) 요청은 상호 TLS(mTLS)를 이용해 인증 및 암호화됩니다.
새로 생성되고 업데이트된 모든 클러스터는 컨트롤 플레인-노드 간 통신에 TLS 1.3을 사용합니다. TLS 1.2는 컨트롤 플레인-노드 간 통신에 지원되는 최소 버전입니다.
노드 간 트래픽: 노드는 Compute Engine VM입니다. Google Cloud 프로덕션 네트워크 내 노드 간 연결은 인증되고 암호화됩니다. 자세한 내용은 전송 중인 데이터 암호화 백서의 VM 간 섹션을 참조하세요.
포드 간 트래픽: 포드가 다른 포드에 요청을 전송할 때 해당 트래픽은 기본적으로 인증되지 않습니다. GKE는 네트워크 계층에서 서로 다른 노드에 있는 포드 간 트래픽을 암호화합니다. 동일한 노드의 포드 간 트래픽은 기본적으로 암호화되지 않습니다. 네트워크 계층 암호화에 대한 자세한 내용은 Google Cloud 가상 네트워크 암호화 및 인증을 참조하세요.
NetworkPolicy으로 포드 간 트래픽을 제한할 수 있습니다. Cloud Service Mesh와 같은 서비스 메시나 다른 애플리케이션 레이어 암호화 방법을 사용해 동일한 노드의 트래픽을 포함한 모든 포드 간 트래픽을 암호화할 수 있습니다.
컨트롤 플레인 구성요소 간 트래픽: 컨트롤 플레인에서 실행되는 다양한 구성요소 간의 트래픽은 TLS를 사용하여 인증되고 암호화됩니다. 트래픽은 방화벽으로 보호되는 Google 소유 네트워크를 벗어나지 않습니다.
신뢰할 수 있는 루트
GKE 구성은 다음과 같습니다.
클러스터 루트 인증 기관(CA)은 API 서버 및 kubelet 클라이언트 인증서의 유효성을 검사하는 데 사용됩니다. 즉, 제어 영역과 노드의 신뢰할 수 있는 루트는 동일합니다. 클러스터 노드 풀 내의 모든 kubelet은 인증서 서명 요청을 제출하여 certificates.k8s.io API를 사용해 이 CA에 인증서를 요청할 수 있습니다. 루트 CA는 클러스터 루트 CA 수명 섹션에 설명된 대로 전체 기간이 제한됩니다.
컨트롤 플레인 VM에서 etcd 데이터베이스 인스턴스를 실행하는 클러스터에서는 별도의 클러스터별 etcd 피어 CA가 etcd 인스턴스 간에 신뢰를 설정하는 데 사용됩니다.
모든 GKE 클러스터에서 별도의 etcd API CA는 Kubernetes API 서버와 etcd API 간의 신뢰를 설정하는 데 사용됩니다.
API 서버 및 kubelet
API 서버와 kubelet은 트러스트에 클러스터 루트 CA를 사용합니다. GKE에서 컨트롤 플레인 API 인증서는 클러스터 루트 CA에 의해 서명됩니다. 클러스터마다 자체 CA가 실행되므로 클러스터 하나의 CA가 손상되더라도 다른 클러스터 CA는 영향을 받지 않습니다.
내부 서비스가 이 CA의 루트 키를 관리하며 이 키를 내보낼 수 없습니다.
이 서비스는 각 GKE 클러스터에 있는 kubelet의 요청을 비롯한 인증서 서명 요청을 수락합니다. 클러스터의 API 서버가 손상되더라도 CA는 손상되지 않으므로 다른 클러스터는 영향을 받지 않습니다.
클러스터의 각 노드에는 클러스터 루트 CA에 인증서 서명 요청을 전송하고 kubelet 클라이언트 인증서를 획득하는 데 사용할 수 있는 공유 보안 비밀이 생성 시 주입됩니다. 그런 다음 이러한 인증서는 kubelet이 API 서버에 요청을 인증하는 데 사용됩니다. 이 공유 보안 비밀은 보안 GKE 노드 또는 GKE용 워크로드 아이덴티티 제휴를 사용 설정하지 않는 한 노드의 포드에서 연결할 수 없습니다.
클러스터 루트 CA 수명
클러스터 루트 CA는 수명이 제한되며, 그 이후로는 만료된 CA에서 서명한 인증서가 유효하지 않습니다. 사용자 인증 정보 사용 기간 확인의 안내에 따라 클러스터 CA의 만료일을 확인합니다.
기존 루트 CA가 만료되기 전에 사용자 인증 정보를 수동으로 순환해야 합니다. CA가 만료되고 사용자 인증 정보를 순환하지 않으면 클러스터가 복구 불가 상태로 전환될 수 있습니다. 복구 불가 클러스터를 방지하기 위한 다음과 같은 메커니즘이 있습니다.
CA가 만료되기 7일 전에 클러스터가 DEGRADED 상태로 전환됩니다.
GKE는 CA가 만료되기 30일 전에 자동 사용자 인증 정보 순환을 시도합니다. 이러한 자동 순환은 유지보수 기간을 무시하므로 GKE에서 새 사용자 인증 정보를 사용하도록 노드를 다시 만들 때 중단이 발생할 수 있습니다. 로컬 환경의 kubectl과 같은 외부 클라이언트는 새 사용자 인증 정보를 사용하도록 업데이트할 때까지 작동하지 않습니다.
GKE 클러스터는 Kubernetes API 객체의 상태를 데이터베이스에 키-값 쌍으로 저장합니다. 컨트롤 플레인의 Kubernetes API 서버는 etcd API를 사용하여 이 데이터베이스와 상호작용합니다. GKE는 다음 기술 중 하나를 사용하여 클러스터 상태 데이터베이스를 실행합니다.
etcd: 클러스터는 컨트롤 플레인 VM에서 실행되는 etcd 인스턴스를 사용합니다.
Spanner: 클러스터는 컨트롤 플레인 VM 외부에서 실행되는 Spanner 데이터베이스를 사용합니다.
클러스터에서 사용하는 데이터베이스 기술과 관계없이 모든 GKE 클러스터는 컨트롤 플레인에서 etcd API를 제공합니다. 클러스터 상태 데이터베이스와 관련된 트래픽을 암호화하기 위해 GKE는 다음 클러스터별 CA 중 하나 또는 둘 모두를 사용합니다.
etcd API CA: etcd API 엔드포인트 간 트래픽에 관한 인증서에 서명하는 데 사용됩니다. etcd API CA는 모든 GKE 클러스터에서 실행됩니다.
etcd 피어 CA: 컨트롤 플레인의 etcd 데이터베이스 인스턴스 간 트래픽에 대한 인증서에 서명하는 데 사용됩니다. etcd 피어 CA는 etcd 데이터베이스를 사용하는 모든 클러스터에서 실행됩니다. Spanner 데이터베이스를 사용하는 클러스터는 etcd 피어 CA를 사용하지 않습니다.
etcd API CA의 루트 키는 컨트롤 플레인이 실행되는 각 Compute Engine 인스턴스의 메타데이터에 배포됩니다. etcd API CA는 클러스터 간에 공유되지 않습니다.
etcd CA 인증서는 5년간 유효합니다. GKE는 이러한 인증서가 만료되기 전에 자동으로 순환합니다.
인증서 순환
모든 클러스터의 API 서버 및 kubelet 인증서를 순환시키려면 사용자 인증 정보 순환을 수행하세요. etcd 인증서의 순환을 트리거하는 방법은 없습니다. 이것은 GKE에서 관리합니다.
[[["이해하기 쉬움","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-07-01(UTC)"],[],[],null,["# Cluster trust\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page describes the trust model in Google Kubernetes Engine (GKE) clusters, including\ncommunication within clusters and how requests are authenticated\nfor components like control planes.\n\nThis document is for\nSecurity specialists who want to understand GKE's cluster trust model.\nTo 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\nBefore reading this page, ensure that you're familiar with the following:\n\n- [General overview of GKE security](/kubernetes-engine/docs/concepts/security-overview)\n- [General overview of GKE networking](/kubernetes-engine/docs/concepts/network-overview)\n\nIntracluster communication\n--------------------------\n\nGKE applies various security mechanisms to traffic between\ncluster components, as follows:\n\n- **Traffic between the control plane and nodes** : the control plane communicates\n with a node for managing containers. When the control plane sends a request,\n (for example, `kubectl logs`) to nodes, the request is sent over a Konnectivity\n proxy tunnel. Requests that the control plane sends are authenticated and\n protected by TLS. When a node sends a\n request to the control plane, for example, from the kubelet to the API server,\n that request is authenticated and encrypted using mutual TLS (mTLS).\n\n All newly created and updated clusters use TLS 1.3 for control plane to node\n communication. TLS 1.2 is the minimum supported version for control plane to\n node communication.\n- **Traffic between nodes** : nodes are Compute Engine VMs. Connections between\n nodes inside the Google Cloud production network are authenticated and\n encrypted. For details, refer to the VM-to-VM section of the\n [Encryption in Transit whitepaper](/docs/security/encryption-in-transit#virtual_machine_to_virtual_machine).\n\n- **Traffic between Pods** : when a Pod sends a request to another Pod, that traffic\n isn't authenticated by default. GKE encrypts traffic between\n Pods on different nodes at the network layer. Traffic between Pods on the\n *same node* isn't encrypted by default. For details about the network-layer\n encryption, see\n [Google Cloud virtual network encryption and authentication](/docs/security/encryption-in-transit#virtual-network).\n\n You can restrict Pod-to-Pod traffic with a\n [NetworkPolicy](/kubernetes-engine/docs/how-to/network-policy), and you can\n encrypt all Pod-to-Pod traffic, including traffic on the same node, by using a\n service mesh like [Cloud Service Mesh](/anthos/service-mesh)\n or a different method of application-layer encryption.\n- **Traffic between control plane components**: traffic between various\n components that run on the control plane is authenticated and encrypted using\n TLS. The traffic never leaves a Google-owned network that's protected by\n firewalls.\n\nRoot of trust\n-------------\n\nGKE has the following configuration:\n\n- The [cluster root Certificate Authority (CA)](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) is used to validate the API server and kubelets' client certificates. That is, control planes and nodes have the same root of trust. Any kubelet within the cluster node pool can request a certificate from this CA using the `certificates.k8s.io` API, by submitting a [certificate signing request](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/#create-a-certificate-signing-request). The root CA has a limited lifetime as described in the [Cluster root CA lifetime](#root-ca-lifetime) section.\n- In clusters that run etcd database instances on the control plane VMs, a separate per-cluster etcd peer CA is used to establish trust between etcd instances.\n- In all GKE clusters, a separate etcd API CA is used to establish trust between the Kubernetes API server and the etcd API.\n\n### API server and kubelets\n\nThe API server and the kubelets rely on the cluster root CA for trust. In\nGKE, the control plane API certificate is signed by the\ncluster root CA. Each cluster runs its own CA, so that if one cluster's CA is\ncompromised, no other cluster CA is affected.\n\nAn internal service manages root keys for this CA, which are non-exportable.\nThis service accepts certificate signing requests, including those from the kubelets\nin each GKE cluster. Even if the API server in a cluster were\ncompromised, the CA would not be compromised, so no other clusters would be\naffected.\n\nEach node in the cluster is injected with a shared secret at creation, which it\ncan use to submit certificate signing requests to the cluster root CA and obtain\nkubelet client certificates. These certificates are then used by the kubelet to\nauthenticate its requests to the API server. This shared secret is reachable by\nPods on the node, unless you enable\n[Shielded GKE Nodes](/kubernetes-engine/docs/how-to/shielded-gke-nodes) or\n[Workload Identity Federation for GKE](/kubernetes-engine/docs/how-to/workload-identity).\n\n#### Cluster root CA lifetime\n\nThe cluster root CA has a limited lifetime, after which any\ncertificates signed by the expired CA are invalid. Check the approximate expiry\ndate of your cluster's CA by following the instructions in\n[Check credential lifetime](/kubernetes-engine/docs/how-to/credential-rotation#check_credential_lifetime).\n\nYou should manually rotate your credentials before your existing root CA\nexpires. If the CA expires and you don't rotate your credentials, your cluster\nmight enter an unrecoverable state. GKE has the following\nmechanisms to try and prevent unrecoverable clusters:\n\n- Your cluster enters a `DEGRADED` state seven days before CA expiry\n- GKE attempts an automatic credential rotation 30 days\n before CA expiry. This automatic rotation ignores maintenance windows and\n might cause disruptions as GKE recreates nodes to use new\n credentials. External clients, like kubectl in local environments, won't\n work until you update them to use the new credentials.\n\n | **Note:** This is a last resort to prevent an unrecoverable cluster. Don't rely on automatic rotation---instead, plan to rotate your credentials manually during maintenance periods well in advance of CA expiry.\n\nTo learn how to perform a rotation, see\n[Rotate your cluster credentials](/kubernetes-engine/docs/how-to/credential-rotation).\n\n### Cluster state storage\n\nGKE clusters store the state of Kubernetes API objects as\nkey-value pairs in a database. The Kubernetes API server in your control plane\ninteracts with this database by using the\n[etcd API](https://etcd.io/docs/latest/learning/api/). GKE uses\none of the following technologies to run the cluster state database:\n\n- **etcd**: the cluster uses etcd instances that run on the control plane VMs.\n- **Spanner** : the cluster uses a [Spanner](/spanner) database that runs outside of the control plane VMs.\n\nRegardless of the database technology that a cluster uses, every\nGKE cluster serves the etcd API in the control plane. To encrypt\ntraffic that involves the cluster state database, GKE uses one or\nboth of the following per-cluster CAs:\n\n- **etcd API CA**: used to sign certificates for traffic to and from etcd API endpoints. An etcd API CA runs in every GKE cluster.\n- **etcd peer CA**: used to sign certificates for traffic between etcd database instances on the control plane. An etcd peer CA runs in any cluster that uses etcd databases. Clusters that use Spanner databases don't use the etcd peer CA.\n\nRoot keys for the etcd API CA are distributed to the metadata of each\nCompute Engine instance that the control plane runs on. The etcd API\nCA isn't shared between clusters.\n\nThe etcd CA certificates are valid for five years. GKE\nautomatically rotates these certificates before they expire.\n\nCertificate rotation\n--------------------\n\nTo rotate all your cluster's API server and kubelet certificates, perform a\n[credential rotation](/kubernetes-engine/docs/how-to/credential-rotation). There is no way for you to trigger a rotation of the etcd\ncertificates; this is managed for you in GKE.\n| **Note:** Performing a credential rotation causes GKE to upgrade all node pools to the closest supported node version, and causes brief downtime for the cluster API.\n\nWhat's next\n-----------\n\n- [Read more about Managing TLS certificates in the Kubernetes documentation](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)."]]
