기본적으로 보안되는 클러스터 VPC 네트워킹 이해

Virtual Private Cloud 1.30 and later

1.30, IBM Cloud Kubernetes Service 에서 생성되는 새로운 VPC 클러스터부터 보안 기본값 클러스터 VPC 네트워킹이라는 새로운 보안 기능을 도입했습니다. 기본적으로 보안을 사용하는 경우 VPC 클러스터를 작성할 때 자동으로 작성되는 새 VPC 설정 (예: 관리 보안 그룹, 보안 그룹 규칙 및 가상 사설 엔드포인트 게이트웨이 (VPE)) 이 있습니다. 버전 1.30 이후 클러스터를 만들 때 생성 및 관리되는 VPC 구성 요소에 대한 다음 세부 정보를 검토하세요.

개요

기본 네트워킹에 의한 보안을 사용하면 새 IBM Cloud Kubernetes Service VPC 클러스터를 버전 1.30 이상에서 프로비저닝할 때 클러스터가 작동하는 데 필요한 트래픽만 허용되고 기타 모든 액세스가 차단됩니다. 기본 네트워킹으로 보안을 구현하기 위해 IBM Cloud Kubernetes Service 은 다양한 보안 그룹 및 보안 그룹 규칙을 사용하여 클러스터 컴포넌트를 보호합니다. 이러한 보안 그룹 및 규칙은 자동으로 작성되어 작업자 노드, 로드 밸런서 및 클러스터 관련 VPE 게이트웨이에 연결됩니다.

Virtual Private Cloud 보안 그룹은 하이퍼바이저 레벨에서 트래픽을 필터링합니다. 보안 그룹 규칙은 특정 순서로 적용되지 않습니다. 그러나 작업자 노드에 대한 요청은 이 요청이 지정된 규칙 중 하나와 일치하는 경우에만 허용됩니다. 인바운드 또는 아웃바운드 규칙을 작성하여 한 방향으로의 트래픽을 허용하면, 반대 방향으로의 응답 또한 허용됩니다. 보안 규칙은 누적되며, 이는 작업자 노드가 둘 이상의 보안 그룹에 연결된 경우 이러한 보안 그룹에 포함된 모든 규칙이 해당 작업자 노드에 적용됨을 의미합니다. 새 클러스터 버전의 kube-<clusterID> 보안 그룹에는 이전 클러스터 버전보다 더 많은 규칙이 있을 수 있습니다. 서비스의 보안을 개선하고 기능을 중단하지 않도록 보안 그룹 규칙이 추가되었습니다.

가상 사설 엔드포인트(VPE) 게이트웨이

IBM Cloud Kubernetes Service 1.28+의 첫 번째 VPC 클러스터가 지정된 VPC에서 작성되거나 해당 VPC의 클러스터에서 마스터가 1.28+로 업데이트되면 다양한 IBM Cloud 서비스에 대해 여러 공유 VPE 게이트웨이가 작성됩니다. 이러한 각 유형의 공유 VPE 게이트웨이 중 하나만 VPC당 작성됩니다. VPC의 모든 클러스터는 이러한 서비스에 대해 동일한 VPE 게이트웨이를 공유합니다. 이러한 공유 VPE 게이트웨이에는 클러스터 작업자가 있는 각 구역의 단일 예약 IP가 지정됩니다.

공유 VPE 게이트웨이

다음 VPE 게이트웨이는 VPC 클러스터를 작성할 때 자동으로 작성됩니다.

공유 VPE 게이트웨이
표에는 VPC 클러스터용으로 생성된 VPE 게이트웨이가 나와 있습니다. 첫 번째 컬럼에는 게이트웨이의 이름이 포함됩니다. 두 번째 열에는 간단한 설명이 포함되어 있습니다. 세 번째 열에는 DNS 이름이 포함됩니다.
VPE 게이트웨이	설명	DNS 이름
IBM Cloud Container Registry	IBM Cloud Container Registry 에서 컨테이너 이미지를 클러스터에서 실행 중인 앱으로 가져옵니다.	`icr.io`, `*.icr.io`
IBM Cloud Object Storage s3 게이트웨이	IBM Cloud Object Storage API에 접속하세요.	`s3.direct.<region>.cloud-object-storage.appdomain.cloud`, `*.s3.direct.<region>.cloud-object-storage.appdomain.cloud`
IBM Cloud Object Storage 구성 게이트웨이	컨테이너 이미지를 다음 주소로 백업 IBM Cloud Object Storage	`config.direct.cloud-object-storage.cloud.ibm.com`
IBM Cloud Kubernetes Service (카-몬, 인-체, 인-맘)	IBM Cloud Kubernetes Service API에 액세스하여 클러스터를 만들고, 워커 풀을 추가하는 등의 작업을 수행하세요.	`private.<region>.containers.cloud.ibm.com`
IBM Cloud Kubernetes Service (기타 지역)	IBM Cloud Kubernetes Service API에 액세스하여 클러스터를 만들고, 워커 풀을 추가하는 등의 작업을 수행하세요.	`api.<region>.containers.cloud.ibm.com`
IBM Cloud VPC	VPC API에 액세스하여 VPC 서비스형 인프라의 일부인 리소스를 프로비저닝하고 관리하세요( IaaS ).	`<region>.private.iaas.cloud.ibm.com`

비공유 VPE 게이트웨이

지원되는 모든 VPC 클러스터에는 클러스터가 생성될 때 계정에 생성되는 클러스터 마스터용 VPE 게이트웨이가 있습니다.

비공유 VPE 게이트웨이
표에는 VPC 클러스터용으로 생성된 VPE 게이트웨이가 나와 있습니다. 첫 번째 컬럼에는 게이트웨이의 이름이 포함됩니다. 두 번째 열에는 간단한 설명이 포함되어 있습니다.
VPE 게이트웨이	설명
IBM Cloud Kubernetes Service 클러스터 마스터	이 VPE 게이트웨이는 클러스터 작업자가 사용하며, 클러스터의 마스터 API 서버에 연결하기 위해 VPC의 다른 항목에서 사용할 수 있습니다. 이 VPE 게이트웨이에는 클러스터 워커가 있는 각 영역에서 단일 예약 IP가 할당되며, 이 IP는 클러스터 워커가 있는 해당 영역의 VPC 서브넷 중 하나에 만들어집니다. †

예를 들어 클러스터에 단일 영역 리전(us-east-1)과 단일 VPC 서브넷에만 작업자가 있는 경우 해당 서브넷에 단일 IP가 생성되어 VPE 게이트웨이에 할당됩니다. 클러스터에 us-east-1, us-east-2 및 us-east-3 와 같은 세 개의 구역 모두에 작업자가 있고 이러한 작업자가 각 구역에 있는 4개의 VPC 서브넷에 분산되어 있는 경우 12개의 VPC 서브넷이 모두 함께 작성되고 각 구역에 하나씩 해당 구역에 있는 4개의 VPC 서브넷 중 하나에 세 개의 IP가 작성됩니다. 서브넷은 무작위로 선택됩니다.

다른 VPC에서 클러스터 마스터 VPE 게이트웨이에 접속하기

클러스터 마스터 VPE 게이트웨이는 클러스터 워커와 동일한 VPC에 있는 모든 리소스가 사설 네트워크를 통해 클러스터 마스터 API 서버에 액세스하는 데 사용됩니다. 동일한 계정 내의 다른 VPC에서 클러스터 마스터에 비공개로 연결해야 하는 경우, 해당 다른 VPC에 동일한 클러스터 마스터를 대상으로 하는 추가 VPE 게이트웨이를 생성할 수 있습니다.

이를 위해 IBM Cloud Kubernetes Service 가 생성한 클러스터 마스터 VPE 게이트웨이의 대상 CRN을 사용하십시오. 새 게이트웨이에 사용할 예약 IP 주소는 직접 제공해야 하며, 보안 그룹과 해당 규칙을 직접 생성하고 관리해야 합니다. VPE 게이트웨이의 발신 규칙은 적용되지 않으며, 수신 규칙만 평가됩니다. ‘ IBM Cloud Kubernetes Service ’은 사용자가 생성한 VPE 게이트웨이 또는 보안 그룹을 관리하거나 수정하지 않습니다.

관리 보안 그룹

IBM Cloud Kubernetes Service 은 VPC 클러스터에 대한 다음 보안 그룹 및 규칙을 자동으로 작성하고 업데이트합니다.

관리형 보안 그룹
표에는 VPC 클러스터에 대해 생성된 관리형 보안 그룹이 나와 있습니다. 첫 번째 열에는 보안 그룹의 이름이 포함됩니다. 두 번째 열에는 이름 지정 규칙이 포함되어 있습니다.
보안 그룹	이름 지정 규칙
작업자 보안 그룹	`kube-<clusterID>`
마스터 VPE 게이트웨이 보안 그룹	`kube-vpegw-<clusterID>`
공유 VPE 게이트웨이 보안 그룹	`kube-vpegw-<vpcID>`
로드 밸런서 서비스 보안 그룹	`kube-lbaas-<clusterID>`

작업자 보안 그룹

IBM Cloud Kubernetes Service VPC 클러스터를 만들면 해당 클러스터의 모든 작업자 또는 노드에 대한 보안 그룹이 만들어집니다.

보안 그룹의 이름은 kube-<clusterID> 입니다. 여기서 <clusterID> 는 클러스터의 ID입니다.
나중에 새 노드가 클러스터에 추가되면 해당 노드가 클러스터 보안 그룹에 자동으로 추가됩니다.
규칙은 로드 밸런서에 의해 필요에 따라 동적으로 추가되거나 제거됩니다.
IBM Cloud Kubernetes Service kube-<clusterID> 보안 그룹의 노드 포트 범위 내에서 및 로 들어오는 트래픽에 대한 규칙만 모니터링합니다. TCP UDP IBM Cloud Kubernetes Service 가 노드 포트 범위 내에서 규칙을 감지했으나 해당 노드 포트 서비스에 해당하는 것이 없는 경우, 해당 규칙을 제거합니다. 노드 포트 서비스로 들어오는 트래픽을 허용하려면, 노드 포트 서비스를 생성한 후에(생성하기 전이 아니라) ‘ kube-<clusterID> ’ 보안 그룹에 필요한 규칙을 추가해야 합니다.
kube-<clusterID> 보안 그룹에 노드 포트 범위 외부에 추가한 추가 규칙은 IBM Cloud Kubernetes Service 에 의해 무시되며 그대로 유지됩니다.
kube-<clusterID> 보안 그룹의 기본 규칙을 수정하거나 제거하지 마십시오. 이렇게 할 경우 클러스터의 워커와 제어 플레인 간의 네트워크 연결에 장애가 발생할 수 있습니다.

kube-clusterID 보안 그룹의 규칙
이 표에는 클러스터 작업자 보안 그룹에 적용되는 규칙이 나와 있습니다. 첫 번째 열에는 규칙의 프로토콜이 포함됩니다. 두 번째 컬럼에는 포트 및 유형이 포함됩니다. 세 번째 열에는 규칙의 원격 대상이 포함됩니다. 네 번째 열에는 규칙에 대한 간략한 설명이 포함되어 있습니다.
설명	방향	프로토콜	포트 또는 값	소스 또는 대상
팟 (Pod) 서브넷에 대한 인바운드 트래픽을 허용합니다.	인바운드	ICMP/ TCP / UDP	모두	172.17.0.0/18 (기본 서브넷 범위) 또는 클러스터를 작성할 때 지정하는 사용자 정의 서브넷 범위입니다.
작업자 대 작업자 통신을 허용하는 자체에 대한 인바운드 액세스를 허용합니다.	인바운드	ICMP/ TCP / UDP	모두	`kube-<clusterID>`
인바운드 ICMP (ping) 액세스를 허용합니다.	인바운드	ICMP	type=8	0.0.0.0/0
로드 밸런서(ALB/NLB)가 연 노드 포트에서 인바운드 트래픽을 허용합니다. 로드 밸런서가 추가되거나 제거되면 규칙이 동적으로 추가되거나 제거됩니다.	인바운드	TCP	로드 밸런서 노드 포트입니다.	`kube-lbaas-<clusterID>`
팟 (Pod) 서브넷에 대한 아웃바운드 트래픽을 허용합니다.	아웃바운드	ICMP/ TCP / UDP	모두	172.17.0.0/18 (기본 서브넷 범위) 또는 클러스터를 작성할 때 지정하는 사용자 정의 서브넷 범위입니다.
작업자를 프로비저닝할 수 있는 마스터 제어 플레인에 대한 아웃바운드 트래픽을 허용합니다.	아웃바운드	ICMP/ TCP / UDP	모두	161.26.0.0/16
작업자 대 작업자 통신을 허용하는 자체에 대한 아웃바운드 액세스를 허용합니다.	아웃바운드	ICMP/ TCP / UDP	모두	`kube-<clusterID>`
마스터 VPE 게이트웨이 보안 그룹에 대한 아웃바운드 트래픽을 허용합니다.	아웃바운드	ICMP/ TCP / UDP	모두	`kube-vpegw-<clusterID>`
공유 VPE 게이트웨이 보안 그룹에 대한 아웃바운드 트래픽을 허용합니다.	아웃바운드	ICMP/ TCP / UDP	모두	`kube-vpegw-<vpcID>`
Ingress ALB를 통해 TCP 트래픽 허용	아웃바운드	TCP	Ports:Min=443,Max=443	ALB 공용 IP 주소 `n`
영역 `n` 에 대한 사용자 지정 DNS 확인자를 통해 TCP 및 UDP 트래픽을 허용합니다.`**`	아웃바운드	TCP/UDP	Min=53,Max=53	`n` 구역의 DNS 분석기 IP 주소입니다.
전체 CSE 서비스 범위에 대한 트래픽을 허용합니다.	아웃바운드	ICMP/ TCP / UDP	모두	166.8.0.0/14
모든 구역의 IAM 사설 엔드포인트에 대한 트래픽을 허용합니다. IP는 지역에 따라 다를 수 있습니다. 클러스터가 있는 구역당 하나의 규칙이 추가됩니다.	아웃바운드	ICMP/ TCP / UDP	모두	모든 구역에 대한 IAM 사설 엔드포인트 IP 주소입니다.
1.33 and later 인스턴스 메타데이터 API로 향하는 아웃바운드 트래픽을 허용합니다.	아웃바운드	ICMP/ TCP / UDP	모두	169.254.169.254
4.18 and later 인스턴스 메타데이터 API로 향하는 아웃바운드 트래픽을 허용합니다.	아웃바운드	ICMP/ TCP / UDP	모두	169.254.169.254

** Hub및 Spoke VPC는 VPC에서 사용자 정의 DNS 분석기를 사용합니다. 트래픽은 각 DNS 분석기의 IP 주소를 통과해야 합니다. 포트 53을 통해 영역당 두 개의 규칙( TCP 및 UDP )이 있습니다.

마스터 VPE 게이트웨이 보안 그룹

VPC 클러스터를 작성할 때 VPE (Virtual Private Endpoint) 게이트웨이가 클러스터와 동일한 VPC에 작성됩니다. 보안의 이름은 kube-vpegw-<clusterID> 이며, 여기서 <clusterID> 는 클러스터의 ID입니다. 이 VPE 게이트웨이의 목적은 IBM Cloud에서 관리하는 클러스터 마스터에 대한 게이트웨이 역할을 하는 것입니다. VPE 게이트웨이에는 클러스터에 작업자가 있는 VPC의 각 구역에 있는 단일 IP 주소가 지정됩니다.

해당 작업자 노드에서만 클러스터의 마스터에 대한 액세스를 허용하기 위해 각 클러스터 마스터 VPE 게이트웨이에 대해 보안 그룹이 작성됩니다. 그런 다음 클러스터 작업자 보안 그룹에서 클러스터 마스터 VPE 게이트웨이의 필수 포트로의 Ingress 연결을 허용하는 원격 규칙이 작성됩니다. 클러스터의 프라이빗 서비스 엔드포인트 VPE 게이트웨이에 연결하기 위해 VPC VPN을 통해 들어오는 연결을 포함한 프라이빗 연결의 경우, 클러스터의 모든 활성 작업자 풀에 대해 서브넷 CIDR에서 TCP 트래픽이 허용됩니다.

마스터 VPE 게이트웨이 보안 그룹의 인바운드 규칙
표에는 마스터 VPE 게이트웨이 보안 그룹에 적용되는 인바운드 규칙이 나와 있습니다. 첫 번째 열에는 규칙의 프로토콜이 포함됩니다. 두 번째 컬럼에는 포트 및 유형이 포함됩니다. 세 번째 열에는 규칙의 원격 대상이 포함됩니다. 네 번째 열에는 규칙에 대한 간략한 설명이 포함되어 있습니다.
설명	방향	프로토콜	포트 또는 값	소스 또는 대상
클러스터 작업자 보안 그룹에서 서버 노드 포트로의 인바운드 트래픽을 허용합니다.	인바운드	TCP	서버 URL 노드 포트	`kube-<clusterID>`
클러스터 작업자 보안 그룹에서 Konnectivity 포트로의 인바운드 트래픽을 허용하십시오.	인바운드	TCP	Konnectivity 포트	`kube-<clusterID>`
클러스터의 모든 활성 워커 풀의 서브넷에서 인바운드 트래픽을 허용합니다.`*`	인바운드	TCP	서버 URL 노드 포트	서브넷 CIDR

* 모든 활성 워커 풀의 서브넷에 대해 하나의 규칙이 추가됩니다. 세 개의 영역에 작업자가 있는 경우 세 개의 규칙이 추가됩니다(해당 영역의 각 서브넷에 대해 하나씩).

공유 VPE 게이트웨이 보안 그룹

VPC 내에서 첫 번째 클러스터를 프로비저닝하면 공유 VPE 게이트웨이 보안 그룹이 생성됩니다. 보안 그룹의 이름은 kube-vpegw- 이며, 여기서 은 사용자의 VPC ID입니다. 이 보안 그룹은 VPC 내의 모든 공유 VPE 게이트웨이에 연결되어 있으며, 해당 게이트웨이를 통해 트래픽을 전송할 수 있는 리소스를 제어합니다.

동일한 VPC에 클러스터가 하나씩 추가될 때마다, 이 보안 그룹에 새로운 클러스터의 ‘ kube-<clusterID> ’ 워커 보안 그룹에서 오는 트래픽을 허용하는 단일 인바운드 원격 규칙이 추가됩니다. VPC의 각 클러스터에 대해 하나의 규칙이 작성됩니다. 클러스터가 프로비저닝될 때 ‘ kube-vpegw-<vpcID> ’ 보안 그룹이 이미 존재하는 경우, 해당 보안 그룹은 인식되어 재사용되며 새로 생성되지는 않습니다.

클러스터를 생성할 때마다 보안 그룹도 추가되며, 하나의 VPC는 최대 100개의 보안 그룹을 지원합니다. 이 제한은 약 33개의 클러스터에서 도달하므로, VPC당 최대 25개의 클러스터를 권장합니다. 자세한 내용은 VPC 할당량 문서를 참조하세요.

공유 VPE 게이트웨이 보안 그룹의 인바운드 규칙
표에는 공유 VPE 게이트웨이 보안 그룹에 적용되는 인바운드 규칙이 나와 있습니다. 첫 번째 열에는 규칙의 목적이 포함됩니다. 두 번째 열에는 규칙의 방향이 포함됩니다. 세 번째 열에는 프로토콜이 포함됩니다. 네 번째 열에는 규칙의 원격 대상이 포함됩니다.
설명	방향	프로토콜	소스 또는 대상
지정된 클러스터로부터의 인바운드 트래픽을 허용합니다.	인바운드	TCP	`kube-<clusterID>`

kube-vpegw-<vpcID> 보안 그룹에 인바운드 규칙을 추가할 수 있습니다. 예를 들어, VPC 내의 VSI 또는 기타 리소스가 공유 VPE 게이트웨이에 액세스할 수 있도록 허용하기 위함입니다. IBM Cloud Kubernetes Service 는 VPC에 추가 클러스터가 프로비저닝되는 경우를 포함하여, 일반적인 클러스터 운영 중에 사용자가 추가한 규칙을 제거하지 않습니다. VSI가 공유 VPE 게이트웨이에 액세스할 수 있도록 허용하는 방법에 대한 안내는 “왜 내 VSI가 VPE 게이트웨이에 액세스할 수 없나요? ”를 참조하십시오.

ibmcloud ks security-group reset 를 실행하면 사용자가 추가한 규칙을 포함하여 보안 그룹의 모든 규칙이 삭제되고, IBM Cloud Kubernetes Service 의 기본 규칙만 복원됩니다.

VPC에 클러스터가 프로비저닝되기 전에 공유 클라우드 서비스 엔드포인트(예: icr.io 또는 s3.direct)에 대한 액세스가 필요한 VSI 또는 기타 리소스가 포함된 경우, ‘ kube-vpegw-<vpcID> ’ 보안 그룹과 공유 VPE 게이트웨이를 직접 생성할 수 있습니다. 나중에 VPC 내에 IBM Cloud Kubernetes Service 클러스터가 프로비저닝되면, 시스템은 기존 보안 그룹을 찾아 이를 재사용하고, 새 클러스터의 워커 보안 그룹에 대한 새로운 인바운드 규칙을 추가합니다.

공유 VPE 게이트웨이를 직접 생성할 때는 ‘ kube-vpegw-<vpcID> ’ 보안 그룹을 해당 게이트웨이에 연결하십시오. ‘ IBM Cloud Kubernetes Service ’은 자신이 생성하지 않은 게이트웨이에는 해당 보안 그룹을 자동으로 연결하지 않습니다.

IBM Cloud Kubernetes Service 이 시스템은 관리하는 공유 VPE 게이트웨이를 이름 접두사를 기준으로 식별합니다. IBM Cloud Kubernetes Service 에서 생성된 게이트웨이는 iks- 형식의 명명 규칙을 따릅니다. 클러스터가 VPC에서 제거될 때 공유 VPE 게이트웨이와 ‘ kube-vpegw-<vpcID> ’ 보안 그룹은 삭제되지 않습니다. ‘ IBM Cloud Kubernetes Service ’는 자신이 생성하지 않은 공유 VPE 게이트웨이의 예약된 IP 주소를 수정하지 않습니다. IBM Cloud Kubernetes Service 에서 생성한 게이트웨이의 이름을 변경하면( iks- 접두사를 제거하면), IBM Cloud Kubernetes Service 는 해당 게이트웨이의 예약된 IP 주소를 더 이상 관리하지 않습니다. 이는 IBM Cloud Kubernetes Service 에서 생성된 게이트웨이의 소유권을 기존 연결 상태를 방해하지 않고 이전하는 공식 지원 방법입니다.

허브-스포크 VPC 구성에서 스포크 VPC가 DNS 확인 작업을 허브 VPC에 위임하는 경우, 클러스터가 스포크 VPC에 프로비저닝될 때 IBM Cloud Kubernetes Service 는 항상 해당 스포크 VPC 내에 공유 VPE 게이트웨이를 생성합니다. 이를 통해 스포크가 허브에서 분리되더라도 연결이 유지됩니다. DNS 위임 경로가 스포크 엔드포인트를 허브를 통해 라우팅하는 경우, 스포크 게이트웨이는 DNS 확인에 사용되지 않습니다. 스포크 VPC 서브넷에서 들어오는 트래픽을 허용하려면 허브의 공유 VPE 게이트웨이에서 보안 그룹을 구성해야 합니다. 자세한 내용은 ‘아웃바운드 트래픽 보호 기능이 적용된 허브 앤 스포크 VPC에 대한 고려 사항’을 참조하십시오.

로드 밸런서 서비스 보안 그룹

각 클러스터에는 해당 클러스터의 모든 로드 밸런서(ALB 및 NLB)에 연결된 ‘ kube-lbaas-<clusterID> ’ 보안 그룹이 하나씩 있습니다. Private Path NLB는 보안 그룹 연결을 지원하지 않습니다.

이 보안 그룹의 규칙은 로드 밸런서가 추가, 업데이트 또는 제거됨에 따라 동적으로 생성 및 업데이트됩니다. IBM Cloud Kubernetes Service 는 이 보안 그룹의 모든 인바운드 및 아웃바운드 규칙을 모니터링하며, 필수 규칙으로 인식되지 않는 불필요한 규칙을 자동으로 제거합니다. ibmcloud ks security-group reset 를 실행하면 모든 규칙이 삭제되고, 기본 IBM Cloud Kubernetes Service 규칙만 복원됩니다.

이 보안 그룹의 아웃바운드 규칙은 외부 포트(예: 80번 및 443번 포트)가 매핑된 워커 노드 포트로 트래픽을 라우팅합니다. kube-lbaas-<clusterID> 보안 그룹에 있는 모든 발신 규칙을 수정하거나 삭제하지 마십시오.

퍼블릭 로드 밸런서로 들어오는 트래픽 제한

일반적인 시나리오는 공용 로드 밸런서로 트래픽을 전송할 수 있는 소스 IP 주소를 제한하는 것입니다. 특정 포트(예: TCP 의 443번 포트)에 대한 인바운드 트래픽을 제한하려면:

해당 포트에 대해 ‘ kube-lbaas-<clusterID> ’ 보안 그룹에 허용되는 소스 IP 주소 또는 CIDR 블록을 지정하여 인바운드 규칙을 추가하십시오. 여러 개의 규칙을 생성하여 여러 소스 IP 주소를 허용할 수 있습니다.
허용된 소스 IP 규칙을 생성한 후, 해당 포트에서 모든 IP 주소(0.0.0.0/0)를 허용하는 기본 인바운드 규칙을 삭제하십시오.

로드 밸런서가 공개하는 모든 인바운드 포트에는 최소한 하나의 규칙이 있어야 합니다. 이 규칙은 모든 IP를 허용하는 기본 규칙이거나, 하나 이상의 사용자 지정 소스 IP 규칙이어야 합니다. 해당 포트에 대한 허용된 소스 IP 규칙을 먼저 추가하지 않은 상태에서 기본 “모든 IP 허용” 규칙을 삭제하면, IBM Cloud Kubernetes Service 에서 “모든 IP 허용” 규칙을 자동으로 다시 생성합니다.

LBaaS 용 사용자 지정 보안 그룹

퍼블릭 로드 밸런서와 프라이빗 로드 밸런서를 모두 사용하고 있으며, 각각에 대해 서로 다른 방화벽 규칙을 적용하고자 하는 경우(예를 들어, 퍼블릭 로드 밸런서에 대해서는 발신 IP를 제한하고, 프라이빗 로드 밸런서에 대해서는 모든 트래픽을 허용하는 경우), 클러스터 기본값을 사용하는 대신 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group 어노테이션을 사용하여 특정 로드 밸런서에 사용자 정의 보안 그룹을 연결할 수 있습니다.

사용자 정의 ‘ LBaaS ’ 보안 그룹을 사용할 경우:

IBM Cloud Kubernetes Service 여전히 누락된 필수 인바운드 규칙이 있으면 자동으로 생성합니다.
IBM Cloud Kubernetes Service 사용자가 사용자 지정 보안 그룹에 추가한 규칙은 절대 삭제되지 않습니다.

로드밸런서 보안 그룹 규칙
표에는 부하 분산 장치 보안 그룹에 적용된 규칙이 나와 있습니다. 첫 번째 열에는 규칙의 목적이 포함됩니다. 두 번째 열에는 규칙의 방향이 포함됩니다. 세 번째 열에는 프로토콜이 포함됩니다. 네 번째 컬럼에는 포트 또는 값이 포함됩니다. 다섯 번째 열에는 규칙의 원격 대상이 포함됩니다.
설명	방향	프로토콜	포트 또는 값	소스 또는 대상
로드 밸런서가 연 노드 포트에 대한 아웃바운드 액세스를 허용합니다. 로드 밸런서에 따라 여러 규칙이 있을 수 있습니다.	아웃바운드	TCP	Node 로드 밸런서에 의해 열린 포트입니다.	`kube-<clusterID>`
로드 밸런서는 포트 80에서 청취하여 해당 포트에서 인바운드 액세스를 허용합니다.	인바운드	TCP	공용 LB 포트입니다. 예 `80`	0.0.0.0/0
로드 밸런서는 해당 포트에서 인바운드 액세스를 허용하는 포트 443에서 청취합니다.	인바운드	TCP	공용 LB 포트입니다. 예 `443`	0.0.0.0/0

사용자 제공 Security Groups

VPC 클러스터를 만들 때 소유하고 있는 보안 그룹을 최대 4개까지 추가로 제공할 수 있습니다.

또한 로드 밸런서 리소스에 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group 어노테이션을 추가하여 사용자 정의 보안 그룹을 로드 밸런서에 연결할 수도 있습니다. 이는 공용 및 사용 로드 밸런서를 모두 보유하고 있으며, 공용 로드 밸런서로 트래픽을 보낼 수 있는 대상을 제한하고자 할 때 유용합니다. 사용자 지정 LBaaS 보안 그룹을 사용할 경우, IBM Cloud Kubernetes Service 에서는 인바운드 트래픽에 대한 규칙을 자동으로 생성하지만, 사용자가 추가한 불필요한 규칙은 자동으로 삭제하지 않습니다. 자세한 내용은 ‘ LBaaS 사용자 지정 보안 그룹’을 참조하십시오.

자세한 내용은 VPC 보안 그룹 만들기 및 관리하기를 참조하세요.

제한사항

작업자 노드 보안 그룹

VPC 클러스터의 워커 노드는 서비스 계정에 속해 있으며 VPC 인프라 대시보드에 표시되지 않기 때문에, 보안 그룹을 생성하여 워커 노드 인스턴스에 적용할 수 없습니다. 기존의 ‘ kube-<clusterID> ’ 보안 그룹만 수정할 수 있습니다.

로깅 및 모니터링

1.30 이상의 클러스터에서 로깅 및 모니터링을 설정할 때 클러스터에 로깅 에이전트를 설치할 때 개인 서비스 엔드포인트를 사용해야 합니다. 공용 엔드포인트가 사용되는 경우 로그 데이터가 저장되지 않습니다.

RHCOS 작업자 노드로 클러스터 모니터링

모니터링 에이전트는 운영 체제의 커널 헤더에 의존하지만 RHCOS에는 커널 헤더가 없습니다. 이 시나리오에서 에이전트는 sysdig.com 에 다시 도달하여 사전 컴파일된 에이전트를 사용합니다. 공용 네트워크에 액세스할 수 없는 클러스터에서는 이 프로세스가 실패합니다. eBPF 이제 새 Sysdig 배포에 대해 기본적으로 사용하도록 설정됩니다. 그러나 기존 클러스터에서 문제가 발생하는 경우 eBPF 이 활성화되어 있는지 확인하고 필요한 경우 활성화하세요. 또는 아웃바운드 트래픽을 허용하거나 에어 갭이 있는 환경에 에이전트를 설치하는 방법에 대한 Sysdig 설명서를 참조하세요.

VPC 클러스터 할당량

클러스터를 생성할 때마다 VPC에 보안 그룹이 추가되며, VPC에는 최대 100개의 보안 그룹을 생성할 수 있습니다. 이 제한은 약 33개의 클러스터에서 도달하므로, VPC당 최대 25개의 클러스터를 권장합니다. 자세한 내용은 VPC 할당량 문서를 참조하세요.

VPC 전송 중 암호화 File Storage.

기본적으로 보안 클러스터와 함께 EIT를 사용하려면 kube-<clusterID> 보안 그룹에 다음 아웃바운드 규칙을 추가해야 합니다.

프로토콜: 아무거나
출처 유형: 모든 유형
출처: 0.0.0.0/0
대상 169.254.169.254.

공용 네트워크를 통한 백업 통신

VPC 클러스터 작업자는 사설 네트워크를 사용하여 클러스터 마스터와 통신합니다. 이전에는 공용 서비스 엔드포인트가 사용으로 설정된 VPC 클러스터의 경우 사설 네트워크가 차단되었거나 사용 불가능한 경우 클러스터 작업자가 클러스터 마스터와 통신하기 위해 공용 네트워크를 사용하도록 폴백할 수 있었습니다. 기본적으로 보안 클러스터에서는 클러스터 작업자의 공용 아웃바운드 트래픽이 차단되기 때문에 공용 네트워크로 폴백하는 것은 옵션이 아닙니다. 이 공용 네트워크 백업 옵션을 허용하기 위해 아웃바운드 트래픽 보호를 사용 안함으로 설정할 수 있지만 더 나은 대안이 있습니다. 대신 사설 네트워크를 통한 작업자 대 마스터 연결에 일시적인 문제가 있는 경우, 이때 kube-clusterID 보안 그룹에 임시 보안 그룹 규칙을 추가하여 클러스터 마스터 apiserver 포트에 대한 아웃바운드 트래픽을 허용할 수 있습니다. 나중에 문제가 해결되면 임시 규칙을 제거할 수 있습니다.

OpenShift Data Foundation및 Portworx 암호화

공용 네트워크 액세스가 없는 클러스터에서 OpenShift Data Foundation 또는 Portworx 를 사용하고 암호화에 Hyper Protect Crypto Services 또는 Key Protect 를 사용하려는 경우 KMS 인스턴스에 대한 액세스를 허용하는 가상 사설 엔드포인트 게이트웨이 (VPE) 를 작성해야 합니다. VPC의 각 서브넷에서 VPE로 하나 이상의 IP 주소를 바인드해야 합니다.