이 페이지에서는 사용자 관리 암호화 키를 사용해서 Google Kubernetes Engine(GKE) 노드 간 포드 통신을 지원하기 위해 전송 중 데이터 암호화를 사용 설정하는 방법을 보여줍니다.
기본적으로 Google은 VM(GKE 포함)에서 실행되는 서비스 또는 애플리케이션에 관계없이 전송 중 데이터의 무결성을 보장하기 위해 네트워크 인터페이스 컨트롤러(NIC) 수준에서 VM 간의 모든 전송 중 데이터를 암호화합니다. 이 암호화 레이어는 모든 GKE 노드 및 포드 트래픽에 적용될 수 있습니다. 암호화 키는 Google에서 제공 및 관리됩니다.
GKE에 대한 노드 간 투명한 암호화를 통해 Google에서는 GKE 노드 간 포드 트래픽을 암호화하는 데 사용되는 암호화 키를 더 세밀하게 제어할 수 있습니다. GKE는 VM NIC에서 제공되는 기본 암호화 외에도 GKE Dataplane V2에서 WireGuard를 사용하여 이 암호화를 수행합니다.
규제 수준이 높은 산업 환경이고 규정 준수 및 보안 감사에 대한 비즈니스 요구가 있을 때는 GKE에서 직접 암호화 키를 제어하는 것이 유용합니다.
단일 및 멀티 클러스터 환경에서 노드 간 투명한 암호화를 사용 설정할 수 있습니다. 이 기능의 작동 방법에 대한 자세한 내용은 GKE에서 노드 간 투명한 암호화 작동 방법을 참조하세요.
제한사항
이 기능만으로는 Google이 GKE 노드 메모리에 저장된 암호화 키에 액세스할 수 없도록 보장되지 않습니다. 일부 규제 환경 또는 행정구에서 또는 특정 규정 준수 요구사항을 충족시키기 위해서는 추가적으로 이러한 키를 암호화하고 액세스를 제어해야 할 수 있습니다. 이렇게 하려면 사용자 관리 암호화 키(CMEK)를 사용하는 Confidential GKE Node에 노드 간 투명한 암호화를 사용하는 것이 좋습니다. CMEK를 사용하는 Confidential GKE Node는 사용자 관리 키를 사용해서 노드의 메모리 콘텐츠를 암호화합니다.
GKE에 대한 노드 간 투명한 암호화는 GKE Dataplane V2 클러스터에서만 지원됩니다.
GKE Autopilot은 지원되지 않습니다.
GKE용 노드 간 투명한 암호화에는 WireGuard가 사용됩니다. WireGuard는 FIPS와 호환되지 않습니다.
암호화 키는 동적으로 순환되지 않습니다. 키를 순환하려면 노드를 재시작하여 수동으로 처리해야 합니다.
Confidential GKE Node와 함께 노드 간 투명한 암호화는 Container-Optimized OS(COS) 및 Ubuntu에서만 작동하며 Windows에서 작동하지 않습니다.
노드 간 투명한 암호화는 GKE 또는
hostNetwork사용 포드로 시작된 네트워크 트래픽을 암호화하지 않습니다.노드 간 투명한 암호화는 노드 포트에 노출된 포드에 전송되는 네트워크 트래픽을 암호화하지 않습니다.
ExternalTrafficPolicy: Cluster가 서비스에 구성되어 있더라도 클라이언트에서 백엔드 포드로 트래픽을 수신하는 첫 번째 노드에서 전달된 트래픽은 암호화되지 않습니다.단일 클러스터 또는 멀티 클러스터 구성에 대해 사용 설정된 노드 간 투명한 암호화에 지원되는 최대 노드 수는 500개입니다.
노드 간 투명한 암호화는 노드 초과 구독을 일으킬 수 있습니다. 처리량이 2Gbps인 Ubuntu OS를 사용하는 n2-standard-8 노드에서 CPU 증가량이 평균 15% 발생할 수 있습니다.
CPU 사용률 증가는 kube-scheduler에서 인식되지 않기 때문에 포드에 기인하지 않습니다. 트래픽이 증가한 포드는 노드의 모든 CPU를 사용할 수 있습니다. 그 결과 올바르게 구성되어 있더라도 다른 포드가 필요한 CPU 리소스를 가져오지 못할 수 있습니다. 따라서 민감한 워크로드를 실행하려는 포드 또는 요청에 빠르게 응답할 수 있어야 하는 포드에 문제가 될 수 있습니다. 문제 해결을 위해서는 노드 간 투명한 암호화가 사용 설정된 노드에서 예약되지 않은 CPU 양을 크게 유지할 수 있습니다. 또는 CPU 요청이 크지만 이 CPU를 사용하지 않는 낮은 PriorityClass를 사용해서 포드를 예약할 수 있습니다.
노드 간 투명한 암호화는 Confidential GKE Node를 사용하지 않는 동일한 영역의 2개 노드에서 150 마이크로초의 지연 시간을 일으킵니다.
노드 간 투명한 암호화를 사용 설정할 경우에는 기본 Google 인프라에서 액세스할 수 없는 키를 사용하여 전송 중 데이터가 암호화되기 때문에 포드에서 트래픽 추적에 사용되는 트래픽 관측 가능성 기능이 예상한 대로 작동하지 않을 수 있습니다.
노드 간 투명한 암호화를 사용 설정하면 포드 IP 주소가 VPC에 표시되지 않습니다. 패킷 미러링 및 포드 CIDR 기반 VPC 방화벽 규칙과 같이 패킷 검사에 의존하는 기능은 노드 간 투명한 암호화와 호환되지 않습니다.
서로 다른 VPC 서브넷에 연결된 클러스터에서 노드 간 투명한 암호화를 사용 설정할 때는 클러스터 노드 간 통신을 허용하도록 방화벽 규칙을 수동으로 만들어야 합니다.
노드 간 투명한 암호화는 GKE Dataplane V2의 일부 레이어 7 기능을 사용 중지합니다. 따라서 FQDN 네트워크 정책 및 노드 간 투명한 암호화를 동시에 사용 설정할 수 없습니다.
이 기능은 노드 내 가시성과 동시에 사용 설정할 수 없습니다.
시작하기 전에
시작하기 전에 다음 태스크를 수행했는지 확인합니다.
- Google Kubernetes Engine API를 사용 설정합니다. Google Kubernetes Engine API 사용 설정
- 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치한 경우
gcloud components update를 실행하여 최신 버전을 가져옵니다.
안내에 따라 GKE Enterprise를 사용 설정합니다.
GKE 노드 간 투명한 암호화는 Google Cloud CLI 버전 458.0.0 이상 및 다음 GKE 버전에서만 지원됩니다.
- 1.26.10-gke.1024000 이상
- 1.27.7-gke.1506000 이상
- 1.28.2-gke.1098000 이상
GKE에 노드 간 투명한 암호화 사용 설정
단일 클러스터 또는 멀티 클러스터 환경에서 GKE에 노드 간 투명한 암호화를 사용 설정할 수 있습니다.
새 클러스터에 노드 간 투명한 암호화 사용 설정
새 클러스터에서 노드 간 투명한 암호화를 사용 설정하려면 다음 안내를 따르세요.
gcloud container clusters create CLUSTER_NAME \ --region=REGION --enable-datapane-v2 \ --in-transit-encryption inter-node-transparent다음을 바꿉니다.
CLUSTER_NAME을 클러스터 이름으로 바꿉니다.REGION을 클러스터의 컴퓨팅 리전으로 바꿉니다.
구성을 확인하려면 다음 명령어를 사용해서 암호화 상태를 확인합니다.
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption출력은 다음과 비슷합니다.
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
기존 클러스터에서 노드 간 투명한 암호화 사용 설정
기존 클러스터에서 노드 간 투명한 암호화를 사용 설정하려면 다음 안내를 따르세요.
gcloud container clusters update CLUSTER_NAME \ --in-transit-encryption inter-node-transparent --region=REGION다음을 바꿉니다.
CLUSTER_NAME을 클러스터 이름으로 바꿉니다.REGION을 클러스터의 컴퓨팅 리전으로 바꿉니다.
Google Cloud CLI 명령어가 성공적으로 완료되었는지 확인하려면 다음 안내를 따르세요.
gcloud container clusters describe CLUSTER_NAME \ --region=REGION --format json | jq .status다음을 바꿉니다.
CLUSTER_NAME을 클러스터 이름으로 바꿉니다.REGION을 클러스터의 컴퓨팅 리전으로 바꿉니다.
상태가 "실행 중"으로 표시될 때까지 기다립니다. GKE에서 노드 간 암호화를 사용 설정하면 노드가 자동으로 다시 시작됩니다. 노드 다시 시작이 수행되고 새 노드에 정책이 적용되려면 몇 시간 정도 걸릴 수 있습니다.
노드가 다시 시작되었는지 확인하려면 다음 안내를 따르세요.
kubectl get nodes각 노드의
AGE필드를 확인하고AGE필드에 새 노드가 반영되는지 확인합니다.구성을 확인하려면 다음 명령어를 사용해서 암호화 상태를 확인하면 됩니다.
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption출력은 다음과 비슷합니다.
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]피어 수가 클러스터에 있는 노드 수보다 하나 더 적은지 확인합니다. 예를 들어 노드가 24개 있는 클러스터에서 피어 수는 23개여야 합니다. 피어 수가 클러스터에 있는 노드 수보다 1개 더 적지 않으면 노드에서 다시
anetd에이전트를 다시 시작합니다.
여러 클러스터에 노드 간 투명한 암호화 사용 설정
Autopilot 클러스터에서는 노드 간 투명한 암호화가 지원되지 않습니다. Fleet에 Autopilot 클러스터가 포함된 경우 암호화가 사용 설정된 표준 클러스터와 통신하지 못할 수 있습니다.
멀티 클러스터 환경에서 노드 간 투명한 암호화를 사용 설정하려면 다음 안내를 따르세요.
Fleet에 클러스터를 등록합니다.
Fleet에 대해 노드간 투명한 암호화를 사용 설정합니다.
gcloud container fleet dataplane-v2-encryption enable --project PROJECT_IDPROJECT_ID를 프로젝트 ID로 바꿉니다.모든 노드의 상태를 확인합니다.
kubectl -n kube-system get pods -l k8s-app=cilium -o name | xargs -I {} kubectl -n kube-system exec -ti {} -- cilium status출력은 다음과 비슷합니다.
... Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 5)] ...
노드 간 투명한 암호화 사용 중지
경우에 따라 성능 향상 또는 애플리케이션 연결 문제 해결을 위해 GKE 클러스터에서 노드 간 투명한 암호화를 사용 중지해야 할 수 있습니다. 이 작업을 진행하기 전에 다음을 고려하세요.
노드 간 투명한 암호화는 전체 클러스터에 대해 사용 설정되며 네임스페이스 또는 포드와 같은 개별 Kubernetes 리소스에서 부분적으로 사용 중지할 수 없습니다.
이 작업을 수행하면 포드 트래픽이 중단되므로 유지보수 기간 중에 작업을 수행합니다.
단일 클러스터
단일 클러스터에서 노드 간 투명한 암호화를 사용 중지하려면 다음 안내를 따르세요.
gcloud container clusters update CLUSTER_NAME \
--region=REGION
--in-transit-encryption none
다음을 바꿉니다.
CLUSTER_NAME: 클러스터의 이름입니다.REGION: 클러스터의 컴퓨팅 리전입니다.
Fleet에 포함된 클러스터에서 사용 중지
다음 두 옵션 중 하나를 사용해서 Fleet에서 클러스터에 대해 암호화를 사용 중지할 수 있습니다.
Fleet에서 클러스터를 완전히 삭제하려면 클러스터를 등록 취소합니다.
또는 Fleet에 클러스터를 유지하지만 암호화를 사용 중지합니다.
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_IDPROJECT_ID를 프로젝트 ID로 바꿉니다.이 명령어로 암호화를 사용 중지하면 각 클러스터의 Wireguard 피어 목록에서 원격 노드 삭제가 시작됩니다. 이 프로세스는 연관된 클러스터 및 노드 수에 따라 완료하는 데 최대 몇 분까지 걸릴 수 있습니다. 업데이트된 피어 수를 보려면 각 클러스터에서 WireGuard 피어 목록을 수동으로 새로고침해야 합니다. 클러스터 관리 도구 또는 다음 명령어를 사용할 수 있습니다.
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
전체 클러스터 Fleet에 대해 사용 중지
Fleet에서 노드 간 투명한 암호화를 사용 중지하려면 다음 안내를 따르세요.
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_IDPROJECT_ID를 프로젝트 ID로 바꿉니다.노드 간 투명한 암호화를 사용 중지하고 이제 사용되지 않는 API를 삭제하려면 Fleet 수준에서 GKE Dataplane V2 API를 사용 중지합니다. 그러면 Fleet에서 실행되는 GKE Dataplane V2 컨트롤러가 사용 중지됩니다.
gcloud services disable gkedataplanev2.googleapis.com \ --project=PROJECT_IDPROJECT_ID를 프로젝트 ID로 바꿉니다.동일한 이름의 클러스터를 효율적으로 관리하고 멀티 클러스터 암호화 활성화를 보장하려면 다음 단계를 수행합니다.
동일한 이름의 클러스터를 새로 만들기 전에 Fleet에서 이전 클러스터를 등록 취소합니다.
새 클러스터를 다시 만든 후 다시 등록합니다.
클러스터 등록 취소를 잊은 경우에는 이전 멤버십을 삭제하고, 새 멤버십으로 새 클러스터를 다시 만듭니다.
이 단계를 수행하지 않으면 Fleet 멤버십을 다시 만들기 전까지 새 클러스터에서 멀티 클러스터 암호화가 활성화되지 않습니다.
GKE에서 노드 간 투명한 암호화 작동 방법
다음 섹션에서는 클러스터에서 사용 설정할 때 노드 간 투명한 암호화가 작동하는 방법을 설명합니다.
서로 다른 노드의 두 포드 간 네트워크 트래픽 암호화
노드 간 투명한 암호화를 사용 설정하면 포드가 서로 다른 노드에 있는 경우 이러한 노드가 포함된 클러스터에 관계없이 GKE Dataplane V2가 포드 간 트래픽을 암호화합니다. 클러스터가 동일한 Fleet에 속한 경우 동일한 암호화 도메인에 포함됩니다.
노드 간 투명한 암호화 구성이 서로 다른 클러스터가 동일한 Fleet에 공존할 수 있습니다. 일부 클러스터만 노드 간 투명한 암호화를 사용하는 멀티 클러스터 환경이 있는 경우 다음 항목을 고려해야 합니다.
동일한 클러스터의 노드 사이에 포드 간 통신은 공개 키/비공개 키 쌍을 사용해서 암호화됩니다.
노드 간 투명한 암호화가 사용 설정된 클러스터의 노드와 노드 간 투명한 암호화가 사용 설정되지 않은 클러스터의 노드 사이에는 포드 간 통신이 실패합니다.
암호화 키 생성 및 사용
이 기능이 사용 설정되어 있으면 클러스터의 모든 GKE 노드가 암호화 키로 알려진 공개 키/비공개 키 쌍을 자동으로 생성합니다.
비공개 키는 디스크가 아닌 메모리에 저장되며 노드를 벗어나지 않습니다. GKE Confidential Nodes를 사용하면 노드 메모리도 여러 키를 사용해서 암호화되기 때문에 키가 손상될 위험이 더 줄어듭니다.
공개 키는 GKE Dataplane V2 제어 영역을 사용하여 다른 노드와 공유되며 동일한 암호화 도메인의 모든 노드에서 액세스할 수 있습니다.
키가 교환된 후 각 노드는 동일한 암호화 도메인의 다른 노드와 WireGuard 터널을 설정할 수 있습니다. 각 터널은 제공된 노드 쌍에 대해 고유합니다.
비공개 키 또는 공개 키 쌍과 세션 키를 사용할 때는 다음 항목을 고려하세요.
비공개 키/공개 키 쌍:
공개 키가 클러스터에 배포되고 클러스터의 모든 노드가 공개 키에 액세스할 수 있습니다.
키 쌍은 노드가 다시 시작될 때 순환됩니다. GKE는 주기적으로 키를 순환하지 않습니다. 키 순환을 수동으로 트리거하려면 노드를 드레이닝하고 다시 시작합니다. 이렇게 하면 원래 키 쌍이 무효화되고 새로운 키 쌍이 생성됩니다.
세션 키:
이 키는 구성할 수 없습니다.
이 키는 2분마다 주기적으로 순환됩니다.
세션 키는 터널에 관련된 노드에만 적용됩니다.