이 페이지는 Cloud Translation API를 통해 번역되었습니다.

사용자 관리 암호화 키로 GKE에서 전송 중 데이터 암호화

표준

이 페이지에서는 사용자 관리 암호화 키를 사용하여 Google Kubernetes Engine(GKE) 노드 간 포드 통신에 사용되는 전송 중 데이터를 암호화하는 방법을 보여줍니다. 규제 수준이 높은 산업 환경이고 규정 준수 및 보안 감사에 대한 비즈니스 니즈가 있는 경우에 암호화 키에 대한 이러한 수준의 제어 기능이 유용합니다. 이 페이지에서는 단일 및 멀티클러스터 환경을 구성하는 방법과 권장사항 및 제한사항을 알아봅니다.

이 페이지는 규정 준수 및 보안 요구사항이 충족되도록 암호화 키를 세밀하게 제어해야 하는 보안 전문가를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참조하세요.

이 페이지를 읽기 전 다음 내용을 숙지해야 합니다.

전송 중인 데이터
VM NIC에서 제공하는 기본 암호화 외에도 GKE가 GKE Dataplane V2에서 암호화를 수행하는 데 사용하는 WireGuard

기본적으로 Google은 VM(GKE 포함)에서 실행되는 서비스 또는 애플리케이션에 관계없이 전송 중 데이터의 무결성을 보장하기 위해 네트워크 인터페이스 컨트롤러(NIC) 수준에서 VM 간의 모든 전송 중 데이터를 암호화합니다. 이 암호화 레이어는 모든 GKE 노드 및 포드 트래픽에 적용될 수 있습니다. 암호화 키는 Google에서 제공 및 관리됩니다.

단일 및 멀티 클러스터 환경에서 노드 간 투명한 암호화를 사용 설정할 수 있습니다. 이 기능의 작동 방법에 대한 자세한 내용은 GKE에서 노드 간 투명한 암호화 작동 방법을 참조하세요.

제한사항

이 기능만으로는 Google이 GKE 노드 메모리에 저장된 암호화 키에 액세스할 수 없도록 보장되지 않습니다. 일부 규제 환경 또는 행정구에서 또는 특정 규정 준수 요구사항을 충족시키기 위해서는 추가적으로 이러한 키를 암호화하고 액세스를 제어해야 할 수 있습니다. 이렇게 하려면 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 명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.
참고: 기존 gcloud CLI 설치의 경우 compute/region 속성을 설정해야 합니다. 주로 영역 클러스터를 사용하는 경우에는 대신 compute/zone을 설정합니다. 기본 위치를 설정하면 gcloud CLI에서 One of [--zone, --region] must be supplied: Please specify location과 같은 오류를 방지할 수 있습니다. 클러스터의 위치가 설정한 기본값과 다른 경우 특정 명령어에서 위치를 지정해야 할 수 있습니다.

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 \
    --location=CONTROL_PLANE_LOCATION \
    --enable-datapane-v2 \
    --in-transit-encryption inter-node-transparent
```
다음을 바꿉니다.
- CLUSTER_NAME을 클러스터 이름으로 바꿉니다.
- CONTROL_PLANE_LOCATION: 클러스터의 컨트롤 플레인에 대한 Compute Engine 위치입니다. 리전 클러스터의 경우 리전 또는 영역 클러스터의 경우 영역을 제공합니다.
참고: 노드 간 암호화를 사용 중지하여 만든 후 나중에 다시 사용 설정하는 대신 노드 간 암호화를 사용 설정하여 새 클러스터를 만드는 것이 좋습니다. 나중에 노드 간 암호화를 사용 설정하면 노드 풀이 다시 시작될 수 있습니다.
구성을 확인하려면 다음 명령어를 사용해서 암호화 상태를 확인합니다.
```
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 에이전트를 다시 시작하세요.

기존 클러스터에서 사용 설정

기존 클러스터에서 노드 간 투명한 암호화를 사용 설정하려면 다음 안내를 따르세요.
```
gcloud container clusters update CLUSTER_NAME \
  --in-transit-encryption inter-node-transparent \
  --location=CONTROL_PLANE_LOCATION
```
다음을 바꿉니다.
- CLUSTER_NAME을 클러스터 이름으로 바꿉니다.
- CONTROL_PLANE_LOCATION: 클러스터의 컨트롤 플레인에 대한 Compute Engine 위치입니다. 리전 클러스터의 경우 리전 또는 영역 클러스터의 경우 영역을 제공합니다.
참고: 이 작업을 수행하면 포드 트래픽이 중단될 수 있으므로 유지보수 기간 중에 수행하는 것이 좋습니다. 클러스터 업데이트 및 노드 간 암호화 네트워크 설치는 완료될 때까지 몇 시간 정도 걸릴 수 있습니다.
Google Cloud CLI 명령어가 성공적으로 완료되었는지 확인하려면 다음 안내를 따르세요.
```
gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format json | jq .status
```
다음을 바꿉니다.
- CLUSTER_NAME을 클러스터 이름으로 바꿉니다.
- CONTROL_PLANE_LOCATION: 클러스터의 컨트롤 플레인에 대한 Compute Engine 위치입니다. 리전 클러스터의 경우 리전 또는 영역 클러스터의 경우 영역을 제공합니다.
상태가 "실행 중"으로 표시될 때까지 기다립니다. 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_ID
```
PROJECT_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)]
...
```
참고: 피어 수가 모든 등록된 클러스터에 있는 노드 수보다 하나 더 적은지 확인합니다. 예를 들어 노드가 24개 있는 클러스터에서 피어 수는 23개여야 합니다. 피어 수가 클러스터에 있는 노드 수보다 1개 더 적지 않으면 노드에서 다시 anetd 에이전트를 다시 시작합니다.

노드 간 투명한 암호화 사용 중지

경우에 따라 성능 향상 또는 애플리케이션 연결 문제 해결을 위해 GKE 클러스터에서 노드 간 투명한 암호화를 사용 중지해야 할 수 있습니다. 이 작업을 진행하기 전에 다음을 고려하세요.

노드 간 투명한 암호화는 전체 클러스터에 대해 사용 설정되며 네임스페이스 또는 포드와 같은 개별 Kubernetes 리소스에서 부분적으로 사용 중지할 수 없습니다.
이 작업을 수행하면 포드 트래픽이 중단되므로 유지보수 기간 중에 작업을 수행합니다.

단일 클러스터에서 사용 중지

단일 클러스터에서 노드 간 투명한 암호화를 사용 중지하려면 다음 안내를 따르세요.

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --in-transit-encryption none

다음을 바꿉니다.

CLUSTER_NAME: 클러스터의 이름입니다.
CONTROL_PLANE_LOCATION: 클러스터의 컨트롤 플레인에 대한 Compute Engine 위치입니다. 리전 클러스터의 경우 리전 또는 영역 클러스터의 경우 영역을 제공합니다.

Fleet에 포함된 클러스터에서 사용 중지

다음 두 옵션 중 하나를 사용해서 Fleet에서 클러스터에 대해 암호화를 사용 중지할 수 있습니다.

Fleet에서 클러스터를 완전히 삭제하려면 클러스터를 등록 취소합니다.
또는 Fleet에 클러스터를 유지하지만 암호화를 사용 중지합니다.
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
PROJECT_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_ID
```
PROJECT_ID를 프로젝트 ID로 바꿉니다.
노드 간 투명한 암호화를 사용 중지하고 이제 사용되지 않는 API를 삭제하려면 Fleet 수준에서 GKE Dataplane V2 API를 사용 중지합니다. 그러면 Fleet에서 실행되는 GKE Dataplane V2 컨트롤러가 사용 중지됩니다.
```
gcloud services disable gkedataplanev2.googleapis.com \
    --project=PROJECT_ID
```
PROJECT_ID를 프로젝트 ID로 바꿉니다.

참고: 이 API는 Fleet의 노드 간 투명한 암호화 기능을 담당합니다. 예기치 않은 동작을 방지하기 위해서는 사용 중지하기 전에 이 API가 Fleet에 있는 다른 항목에 사용되지 않는지 확인해야 합니다.

동일한 이름의 클러스터를 효율적으로 관리하고 멀티 클러스터 암호화 활성화를 보장하려면 다음 단계를 수행합니다.
1. 동일한 이름의 클러스터를 새로 만들기 전에 Fleet에서 이전 클러스터를 등록 취소합니다.
2. 새 클러스터를 다시 만든 후 다시 등록합니다.
3. 클러스터 등록 취소를 잊은 경우에는 이전 멤버십을 삭제하고, 새 멤버십으로 새 클러스터를 다시 만듭니다.
이 단계를 수행하지 않으면 Fleet 멤버십을 다시 만들기 전까지 새 클러스터에서 멀티 클러스터 암호화가 활성화되지 않습니다.

GKE에서 노드 간 투명한 암호화 작동 방법

다음 섹션에서는 클러스터에서 사용 설정할 때 노드 간 투명한 암호화가 작동하는 방법을 설명합니다.

서로 다른 노드의 두 포드 간 네트워크 트래픽 암호화

노드 간 투명한 암호화를 사용 설정하면 포드가 서로 다른 노드에 있는 경우 이러한 노드가 포함된 클러스터에 관계없이 GKE Dataplane V2가 포드 간 트래픽을 암호화합니다. 클러스터가 동일한 Fleet에 속한 경우 동일한 암호화 도메인에 포함됩니다.

노드 간 투명한 암호화 구성이 서로 다른 클러스터가 동일한 Fleet에 공존할 수 있습니다. 일부 클러스터만 노드 간 투명한 암호화를 사용하는 멀티 클러스터 환경이 있는 경우 다음 항목을 고려해야 합니다.

동일한 클러스터의 노드 사이에 포드 간 통신은 공개 키/비공개 키 쌍을 사용해서 암호화됩니다.
노드 간 투명한 암호화가 사용 설정된 클러스터의 노드와 노드 간 투명한 암호화가 사용 설정되지 않은 클러스터의 노드 사이에는 포드 간 통신이 실패합니다.

암호화 키 생성 및 사용

이 기능이 사용 설정되어 있으면 클러스터의 모든 GKE 노드가 암호화 키로 알려진 공개 키/비공개 키 쌍을 자동으로 생성합니다.

비공개 키는 디스크가 아닌 메모리에 저장되며 노드를 벗어나지 않습니다. GKE Confidential Nodes를 사용하면 노드 메모리도 여러 키를 사용해서 암호화되기 때문에 키가 손상될 위험이 더 줄어듭니다.
공개 키는 GKE Dataplane V2 제어 영역을 사용하여 다른 노드와 공유되며 동일한 암호화 도메인의 모든 노드에서 액세스할 수 있습니다.

키가 교환된 후 각 노드는 동일한 암호화 도메인의 다른 노드와 WireGuard 터널을 설정할 수 있습니다. 각 터널은 제공된 노드 쌍에 대해 고유합니다.

비공개 키 또는 공개 키 쌍과 세션 키를 사용할 때는 다음 항목을 고려하세요.

비공개 키/공개 키 쌍:
- 공개 키가 클러스터에 배포되고 클러스터의 모든 노드가 공개 키에 액세스할 수 있습니다.
- 키 쌍은 노드가 다시 시작될 때 순환됩니다. GKE는 주기적으로 키를 순환하지 않습니다. 키 순환을 수동으로 트리거하려면 노드를 드레이닝하고 다시 시작합니다. 이렇게 하면 원래 키 쌍이 무효화되고 새로운 키 쌍이 생성됩니다.
세션 키:
- 이 키는 구성할 수 없습니다.
- 이 키는 2분마다 주기적으로 순환됩니다.
- 세션 키는 터널에 관련된 노드에만 적용됩니다.