설명
GKE 노드와 제어 영역의 공개 접근은 별도로 관리해야 합니다. 프라이빗 노드는 외부 IP 없이 동작하지만, 이것만으로 제어 영역의 외부 IP 엔드포인트까지 비활성화되지는 않습니다. 공개 경로가 필요한지 확인하고 네트워크 제한과 IAM·Kubernetes RBAC 권한을 함께 적용하세요.
잠재적 영향
- 연결 가능한 공개 경로와 넓은 방화벽 허용이 있으면 노드의 서비스에 불필요한 연결이 시도될 수 있습니다.
- 제어 영역에 대한 접근 범위가 넓고 인증 정보나 권한이 악용되면 워크로드와 클러스터 설정이 변경될 수 있습니다. 공개 엔드포인트 자체가 인증을 없애지는 않습니다.
해결 방법
- 내부용 노드에는 프라이빗 노드를 사용하고 필요한 외부 통신과 관리 경로를 준비하세요.
- 제어 영역의 IP 엔드포인트와 DNS 엔드포인트를 각각 점검하세요. 외부 IP 엔드포인트를 비활성화하거나 필요한 관리 출발지만 허용하고, DNS 접근에는 적절한 IAM 및 네트워크 통제를 적용하세요.
- 지원되는 GKE 관리 절차로 설정을 변경하고 운영자, 자동화와 노드의 연결을 시험하세요. 강한 인증과 최소 권한의 RBAC를 유지하세요.
예시
새 클러스터의 설정을 비교하는 발췌입니다. 사용 버전에 맞는 VPC·서브넷, IP 할당 및 필요한 제어 영역 CIDR, 프로젝트와 인증 정보는 별도로 구성하세요. 현재 GKE에서 지원하지 않는 기본 사용자 이름·비밀번호 인증은 포함하지 않았습니다.
변경 전
yaml
- name: create a cluster1
google.cloud.gcp_container_cluster:
name: my-cluster1
initial_node_count: 2
node_config:
machine_type: n1-standard-4
disk_size_gb: 500
location: us-central1-a
project: "{{ project_id }}"
auth_kind: serviceaccount
service_account_file: "/tmp/auth.pem"
state: present
- name: create a cluster4
google.cloud.gcp_container_cluster:
name: my-cluster4
initial_node_count: 2
node_config:
machine_type: n1-standard-4
disk_size_gb: 500
location: us-central1-a
project: "{{ project_id }}"
auth_kind: serviceaccount
service_account_file: "/tmp/auth.pem"
state: present
private_cluster_config:
enable_private_endpoint: no
enable_private_nodes: yes
첫 설정은 프라이빗 네트워크 구성을 명시하지 않습니다. 두 번째는 프라이빗 노드를 사용하지만 외부 IP 엔드포인트는 비활성화하지 않습니다.
변경 후
yaml
- name: create a cluster
google.cloud.gcp_container_cluster:
name: my-cluster
initial_node_count: 2
node_config:
machine_type: n1-standard-4
disk_size_gb: 500
location: us-central1-a
project: "{{ project_id }}"
auth_kind: serviceaccount
service_account_file: /tmp/auth.pem
state: present
private_cluster_config:
enable_private_endpoint: yes
enable_private_nodes: yes
enable_private_nodes와 enable_private_endpoint를 함께 설정합니다. DNS 엔드포인트 접근은 별도로 확인해야 합니다. 서로 다른 이름의 새 클러스터 예시이므로 기존 클러스터를 변경하거나 워크로드를 이전하는 절차를 대신하지 않습니다.