이 페이지에서는 Google Kubernetes Engine(GKE)이 Google Cloud에서 자동으로 생성하는 방화벽 규칙을 설명합니다.
기본 Google Cloud 프로젝트에는 이 페이지에 나열된 GKE 관련 규칙 외에도 자동 입력된 방화벽 규칙이 포함됩니다. GKE 클러스터는 일반적으로 VPC 네트워크 내에 배포됩니다. 이러한 규칙은 GKE 클러스터에 대해 기본적인 네트워크 액세스 권한을 부여합니다. 기본 클러스터 작업의 경우 이러한 규칙으로 충분하지만 특정 요구에 따라 추가 규칙을 만들어야 할 수 있습니다.
방화벽 규칙
GKE는 다음 리소스를 만들 때 자동으로 방화벽 규칙을 만듭니다.
- GKE 클러스터
- GKE 서비스
- GKE 게이트웨이 및 HTTPRoutes
- GKE 인그레스
별도로 지정하지 않으면 자동으로 생성되는 모든 방화벽 규칙의 우선순위는 1,000이며 이는 방화벽 규칙의 기본값입니다. 방화벽 동작을 보다 세부적으로 제어하려면 우선순위가 높은 방화벽 규칙을 만들면 됩니다. 우선순위가 더 높은 방화벽 규칙은 자동으로 생성된 방화벽 규칙보다 먼저 적용됩니다.
GKE 클러스터 방화벽 규칙
GKE는 클러스터를 만들 때 다음 인그레스 방화벽 규칙을 만듭니다.
| 이름 | 목적 | 소스 | 대상(목적지 정의) | 프로토콜 및 포트 | 우선순위 |
|---|---|---|---|---|---|
gke-[cluster-name]-[cluster-hash]-master |
비공개 Autopilot 및 Standard 클러스터 전용입니다. 컨트롤 플레인이 클러스터 노드의 Kubelet 및 metric-server에 액세스할 수 있도록 허용합니다. | 컨트롤 플레인 IP 주소 범위(/28) | 노드 태그 | TCP: 443(metrics-server) 및 TCP: 10250(kubelet) | 1000 |
gke-[cluster-name]-[cluster-hash]-vms
|
Kubernetes 네트워킹 모델에 필요한 클러스터 내 통신에 사용됩니다. 노드에서 실행되는 소프트웨어가 노드 IP 주소와 일치하는 소스를 사용하여 패킷을 클러스터의 목적지 포드 IP 및 노드 IP 주소로 전송하도록 허용합니다. 예를 들어 이 규칙에서 허용하는 트래픽은 다음과 같습니다.
|
노드 IP 주소 범위 또는 이 노드 IP 주소 범위의 상위 집합:
|
노드 태그 | TCP: 1-65535, UDP: 1-65535, ICMP | 1000 |
gke-[cluster-name]-[cluster-hash]-all |
Kubernetes 네트워킹 모델에서 필요에 따라 클러스터의 모든 포드 간 트래픽을 허용합니다. |
pod CIDR 인접하지 않은 다중 포드 CIDR이 사용 설정된 클러스터의 경우 클러스터에서 사용되는 모든 포드 CIDR 블록이 사용됩니다. |
노드 태그 | TCP, UDP, SCTP, ICMP, ESP, AH | 1000 |
gke-[cluster-hash]-ipv6-all |
이중 스택 네트워크 클러스터 전용입니다. 클러스터의 노드와 포드 간의 트래픽을 허용합니다. |
|
노드 태그 | TCP, UDP, SCTP, IPv6용 ICMP, ESP, AH | 1000 |
gke-[cluster-name]-[cluster-hash]-inkubelet |
버전 1.23.6 이상을 실행하는 새 GKE 클러스터의 내부 포드 CIDR 및 노드 CIDR에서 포트 10255(kubelet 읽기 전용 포트)에 대한 액세스를 허용합니다. 1.26.4-gke.500 이상 버전을 실행하는 클러스터는 대신 kubelet 인증 포트(10250)를 사용합니다. 클러스터 내에서 10250을 차단하는 방화벽 규칙을 추가하지 마세요. |
내부 포드 CIDR 및 노드 CIDR |
노드 태그 | TCP: 10255 | 999 |
gke-[cluster-name]-[cluster-hash]-exkubelet |
버전 1.23.6 이상을 실행하는 새 GKE 클러스터에서 포트 10255에 대한 공개 액세스를 거부합니다. |
0.0.0.0/0 |
노드 태그 | TCP: 10255 | 1000 |
GKE 서비스 방화벽 규칙
GKE는 서비스를 만들 때 다음 인그레스 방화벽 규칙을 만듭니다.
| 이름 | 목적 | 소스 | 대상(목적지 정의) | 프로토콜 및 포트 |
|---|---|---|---|---|
k8s-fw-[loadbalancer-hash] |
인그레스 트래픽이 서비스에 도달하도록 허용합니다. | 소스는 spec.loadBalancerSourceRanges에서 가져옵니다. spec.loadBalancerSourceRanges가 생략된 경우 기본값은 0.0.0.0/0입니다.
자세한 내용은 방화벽 규칙 및 소스 IP 주소 허용 목록을 참조하세요. |
LoadBalancer 가상 IP 주소 | 서비스 매니페스트에 지정된 포트의 TCP 및 UDP입니다. |
k8s-[cluster-id]-node-http-hc |
externalTrafficPolicy가 Cluster로 설정된 경우 외부 패스 스루 네트워크 부하 분산기 서비스의 상태 점검을 허용합니다. |
|
LoadBalancer 가상 IP 주소 | TCP: 10256 |
k8s-[loadbalancer-hash]-http-hc |
externalTrafficPolicy가 Local로 설정된 경우 외부 패스 스루 네트워크 부하 분산기 서비스의 상태 점검을 허용합니다. |
|
노드 태그 | spec.healthCheckNodePort로 정의된 TCP 포트입니다. spec.healthCheckNodePort가 생략된 경우 기본값은 TCP 포트 번호 10256입니다.
자세한 내용은 상태 점검 포트를 참조하세요. |
k8s-[cluster-id]-node-hc |
externalTrafficPolicy가 Cluster로 설정된 경우 내부 패스 스루 네트워크 부하 분산기 서비스의 상태 점검을 허용합니다.
|
|
노드 태그 | TCP: 10256 |
[loadbalancer-hash]-hc |
externalTrafficPolicy가 Local로 설정된 경우 내부 패스 스루 네트워크 부하 분산기 서비스의 상태 점검을 허용합니다.
|
|
노드 태그 | spec.healthCheckNodePort로 정의된 TCP 포트입니다. spec.healthCheckNodePort가 생략된 경우 기본값은 TCP 포트 번호 10256입니다.
자세한 내용은 상태 점검 포트를 참조하세요. |
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] |
다음 중 하나가 사용 설정된 경우 인그레스 트래픽이 서비스에 도달하도록 허용합니다.
|
소스는 spec.loadBalancerSourceRanges에서 가져옵니다. spec.loadBalancerSourceRanges가 생략된 경우 기본값은 0.0.0.0/0입니다.
자세한 내용은 방화벽 규칙 및 소스 IP 주소 허용 목록을 참조하세요. |
LoadBalancer 가상 IP 주소 | 서비스 매니페스트에 지정된 포트의 TCP 및 UDP입니다. |
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash]-fw |
externalTrafficPolicy가 Local로 설정되고 다음이 사용 설정되면 서비스의 상태 점검이 허용됩니다.
|
|
LoadBalancer 가상 IP 주소 | spec.healthCheckNodePort로 정의된 TCP 포트입니다. spec.healthCheckNodePort가 생략된 경우 기본값은 TCP 포트 번호 10256입니다.
자세한 내용은 상태 점검 포트를 참조하세요. |
k8s2-[cluster-id]-l4-shared-hc-fw |
externalTrafficPolicy가 Cluster로 설정되고 다음이 사용 설정되면 서비스의 상태 점검이 허용됩니다.
|
|
노드 태그 | TCP: 10256 |
gke-[cluster-name]-[cluster-hash]-mcsd |
컨트롤 플레인이 멀티 클러스터 서비스에 대해 클러스터 노드에서 kubelet 및 metrics-server에 액세스하도록 허용합니다. 이 규칙의 우선순위는 900입니다. | 상태 확인 IP 주소 | 노드 태그 | TCP, UDP, SCTP, ICMP, ESP, AH |
GKE 게이트웨이 방화벽 규칙
GKE는 게이트웨이 및 HTTPRoute 리소스를 만들 때 다음 게이트웨이 방화벽 규칙을 만듭니다.
| 이름 | 목적 | 소스 | 대상(목적지 정의) | 프로토콜 및 포트 |
|---|---|---|---|---|
|
네트워크 엔드포인트 그룹(NEG)의 상태 점검을 허용합니다. 첫 번째 게이트웨이 리소스가 생성되면 게이트웨이 컨트롤러가 이 규칙을 만듭니다. 추가 게이트웨이 리소스가 생성되면 게이트웨이 컨트롤러가 이 규칙을 업데이트할 수 있습니다. |
|
노드 태그 | TCP: 모든 컨테이너 대상 포트(NEG용) |
GKE 인그레스 방화벽 규칙
GKE는 인그레스를 만들 때 다음 인그레스 방화벽 규칙을 만듭니다.
| 이름 | 목적 | 소스 | 대상(목적지 정의) | 프로토콜 및 포트 |
|---|---|---|---|---|
k8s-fw-l7-[random-hash] |
첫 번째 인그레스 리소스가 생성되면 인그레스 컨트롤러가 이 규칙을 만듭니다. 추가 인그레스 리소스가 생성되면 인그레스 컨트롤러가 이 규칙을 업데이트할 수 있습니다. |
|
노드 태그 | TCP: 30000-32767, TCP:80 (내부 애플리케이션 부하 분산기용), TCP: 모든 컨테이너 대상 포트(NEG용) |
공유 VPC
공유 VPC에 있는 클러스터에 공유 VPC 네트워크가 사용될 경우 인그레스 컨트롤러가 서비스 프로젝트의 GKE 서비스 계정을 사용하여 호스트 프로젝트에서 인그레스 허용 방화벽 규칙을 만들고 업데이트할 수 없습니다. GKE 서비스 계정에 방화벽 리소스를 만들고 관리할 수 있는 서비스 프로젝트 권한을 부여할 수 있습니다. 자세한 내용은 공유 VPC를 참조하세요.
확장된 서브넷에 필요한 방화벽 규칙
클러스터 서브넷의 기본 IPv4 범위를 확장하면 GKE는 gke-[cluster-name]-[cluster-hash]-vms 방화벽 규칙의 소스 범위를 자동으로 업데이트하지 않습니다. 클러스터의 노드는 서브넷 기본 IPv4 범위의 확장된 부분에서 IPv4 주소를 수신할 수 있으므로, 클러스터의 노드 간에 통신을 허용하도록 방화벽 규칙을 수동으로 만들어야 합니다.
만들어야 하는 인그레스 방화벽 규칙은 확장된 기본 서브넷 IPv4 소스 범위의 TCP 및 ICMP 패킷을 허용해야 하며, 최소한 클러스터의 모든 노드에 적용되어야 합니다.
클러스터의 노드에만 적용되는 인그레스 방화벽 규칙을 만들려면 방화벽 규칙의 대상을 클러스터의 자동으로 생성된 gke-[cluster-name]-[cluster-hash]-vms 방화벽 규칙에서 사용하는 것과 동일한 대상 태그로 설정합니다.
규칙 평가 순서
VPC 방화벽 규칙에 추가로 방화벽 정책을 사용하는 경우 기본적으로 Google Cloud는 네트워크 방화벽 정책(전역 및 리전 모두)보다 먼저 방화벽 규칙을 평가합니다. 규칙 평가 순서를 변경하면 트래픽이 GKE 클러스터에 도달하지 않을 수 있습니다. 자세한 내용은 정책 및 규칙 평가 순서를 참조하세요.
방화벽 규칙 로깅
방화벽 규칙 로깅은 기본적으로 사용 중지되어 있습니다. 방화벽 규칙에 로깅을 사용 설정하려면 --enable-logging 명령어를 사용합니다.
다음 단계
- GKE에서의 네트워킹 개요 읽어보기
- 애플리케이션의 네트워크 정책 구성 알아보기
- Google Cloud의 기타 자동 입력 방화벽 규칙 알아보기
- 공유 VPC를 사용하는 프로젝트에서 방화벽 규칙 만들기에 대해 자세히 알아보기