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

가상 프라이빗 클라우드 4.15 이후

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

개요

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

VPC 보안
이미지는 VPC 및 클러스터에 적용된 VPC 보안 그룹을 보여줍니다

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

가상 프라이빗 엔드포인트(VPE) 게이트웨이

Red Hat OpenShift on IBM Cloud 4.14+의 첫 번째 VPC 클러스터가 지정된 VPC에서 작성되거나 해당 VPC의 클러스터에서 마스터가 4.14+로 업데이트되면 다양한 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
Red Hat OpenShift on IBM Cloud (카-몬, 인-체, 인-맘) Red Hat OpenShift on IBM Cloud API에 액세스하여 클러스터를 만들고, 워커 풀을 추가하는 등의 작업을 수행하세요. private.<region>.containers.cloud.ibm.com
Red Hat OpenShift on IBM Cloud (기타 지역) Red Hat OpenShift on IBM Cloud 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 게이트웨이 설명
Red Hat OpenShift on IBM Cloud 클러스터 마스터 이 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가 작성됩니다. 서브넷은 무작위로 선택됩니다.

관리 보안 그룹

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

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

작업자 보안 그룹

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

  • 보안 그룹의 이름은 kube-<clusterID> 입니다. 여기서 <clusterID> 는 클러스터의 ID입니다.
  • 나중에 새 노드가 클러스터에 추가되면 해당 노드가 클러스터 보안 그룹에 자동으로 추가됩니다.
  • 규칙은 로드 밸런서에 의해 필요에 따라 동적으로 추가되거나 제거됩니다.
  • 노드 포트 범위에 추가된 규칙은 필요하지 않은 경우 자동으로 제거됩니다. 고객이 노드 포트 서비스로 들어오는 트래픽을 허용하려면 노드 포트 서비스를 만든 후에 트래픽을 허용하는 규칙을 추가해야 합니다.
  • 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>
클러스터가 있는 MZR의 모든 구역에 대해 oauth 포트를 통해 공용 엔드포인트에 대한 트래픽을 허용합니다.* 아웃바운드 TCP Oauth 포트 MZR의 모든 구역에 대한 공용 엔드포인트 IP입니다.
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 주소입니다.
인스턴스 메타데이터 API에 대한 아웃바운드 트래픽을 허용합니다. 아웃바운드 ICMP/ TCP / UDP 모두 169.254.169.254
4.18 이후 인스턴스 메타데이터 API에 대한 아웃바운드 트래픽을 허용합니다. 아웃바운드 ICMP/ TCP / UDP 모두 169.254.169.254

* 이러한 규칙은 OAuth 포트를 통해 OpenShift 웹 콘솔 및 공용 엔드포인트에 액세스할 수 있도록 설정된 공용 서비스 엔드포인트가 있는 클러스터에만 추가됩니다. 클러스터가 있는 다중 구역 지역 (MZR) 의 각 구역에 대해 하나의 규칙이 추가됩니다. 클러스터가 3개의 구역이 있는 MZR에 있는 경우 3개의 규칙이 작성됩니다.

** 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 게이트웨이 보안 그룹의 인바운드 규칙
이 표에는 클러스터 작업자 보안 그룹에 적용되는 인바운드 규칙이 나와 있습니다. 첫 번째 열에는 규칙의 목적이 포함됩니다. 두 번째 열에는 규칙의 방향이 포함됩니다. 세 번째 열에는 프로토콜이 포함됩니다. 네 번째 컬럼에는 포트 또는 값이 포함됩니다. 다섯 번째 열에는 규칙의 원격 대상이 포함됩니다.
설명 방향 프로토콜 포트 또는 값 소스 또는 대상
클러스터 작업자 보안 그룹에서 서버 노드 포트로의 인바운드 트래픽을 허용합니다. 인바운드 TCP 서버 URL 노드 포트 kube-<clusterID>
클러스터 작업자 보안 그룹에서 openVPN 또는 Konnectivity 포트로의 인바운드 트래픽을 허용합니다. 인바운드 TCP Konnectivity 포트 kube-<clusterID>
클러스터 작업자 보안 그룹에서 Oauth 포트로의 인바운드 트래픽을 허용합니다. 인바운드 TCP Oauth 포트 kube-<clusterID>
CoreOS-enabled 클러스터만 해당됩니다. 클러스터 작업자 보안 그룹에서 점화 서버 포트로의 인바운드 트래픽을 허용합니다. 인바운드 TCP Ignition 서버 포트 kube-<clusterID>
클러스터의 모든 활성 워커 풀의 서브넷에서 인바운드 트래픽을 허용합니다.* 인바운드 TCP 서버 URL 노드 포트 서브넷 CIDR
클러스터의 모든 활성 워커 풀의 서브넷에서 인바운드 트래픽을 허용합니다.* 인바운드 TCP OAuth 포트 서브넷 CIDR

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

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

공유 VPE 게이트웨이는 VPC의 첫 번째 클러스터가 provisioned.The 클러스터를 만들 때 (이전 클러스터에서 아직 존재하지 않는 경우) 공유 VPE 게이트웨이 보안 그룹이 만들어집니다. 보안 그룹의 이름은 kube-vpegw-<vpcID> 이며, 여기서 <vpcID> 는 VPC의 ID입니다. 그런 다음 지정된 클러스터의 클러스터 작업자 보안 그룹에서 Ingress 연결을 허용하는 원격 규칙이 작성됩니다. 공유 VPE 게이트웨이 보안 그룹에는 해당 VPC의 모든 클러스터가 공유하는 VPE 게이트웨이가 포함되어 있습니다. 공유 VPE 게이트웨이는 이후 버전에 추가되어 다른 IBM Cloud 서비스에 연결할 수 있도록 할 수 있습니다.

클러스터가 프로비저닝될 때 이 공유 VPE 게이트웨이 보안 그룹이 이미 존재하는 경우 프로비저닝 프로세스에서 인식되며 다시 작성되지 않습니다. 그러나 기존 공유 VPE 게이트웨이 보안 그룹과 새 작업자 보안 그룹 사이에는 여전히 원격 규칙이 추가됩니다. 이는 지정된 VPC의 모든 클러스터에서 연결이 허용되도록 하기 위해 수행됩니다. VPC의 각 클러스터에 대해 하나의 규칙이 작성됩니다.

다른 보안 그룹을 소스 또는 대상으로 대상 지정할 수 있는 최대 15개의 규칙이 있습니다. 기본적으로 Red Hat OpenShift on IBM Cloud 는 VPC의 각 클러스터에 대해 kube-<clusterID> 보안 그룹을 대상으로 하는 규칙 1개를 적용합니다. 이 할당량으로 인해 지정된 VPC에서 15개의 클러스터만 작성할 수 있습니다. 자세한 정보는 VPC 할당량 을 참조하십시오.

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

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

모든 로드 밸런서 (ALB및 NLB) 에 첨부되는 기본 보안 그룹입니다.

  • 각 클러스터는 클러스터의 모든 로드 밸런서가 공유하는 고유한 보안 그룹을 가져옵니다.
  • 보안 그룹의 이름은 kube-lbaas-<clusterID> 이며, 여기서 <clusterID> 는 클러스터의 ID입니다.
  • 이 보안 그룹의 규칙은 로드 밸런서가 추가, 제거 또는 업데이트될 때 동적으로 추가 또는 삭제됩니다. SDNLB는 보안 그룹 첨부를 지원하지 않습니다.
  • 이 보안 그룹에 규칙을 추가할 수 있습니다. 그러나 일부 규칙은 다른 규칙과 호환되지 않거나 기능을 방해하는 경우 삭제될 수 있습니다.
로드밸런서 보안 그룹 규칙
표에는 부하 분산 장치 보안 그룹에 적용된 규칙이 나와 있습니다. 첫 번째 열에는 규칙의 목적이 포함됩니다. 두 번째 열에는 규칙의 방향이 포함됩니다. 세 번째 열에는 프로토콜이 포함됩니다. 네 번째 컬럼에는 포트 또는 값이 포함됩니다. 다섯 번째 열에는 규칙의 원격 대상이 포함됩니다.
설명 방향 프로토콜 포트 또는 값 소스 또는 대상
로드 밸런서가 연 노드 포트에 대한 아웃바운드 액세스를 허용합니다. 로드 밸런서에 따라 여러 규칙이 있을 수 있습니다. 아웃바운드 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개까지 추가로 제공할 수 있습니다.

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

제한사항

작업자 노드 보안 그룹
VPC 클러스터의 작업자 노드는 서비스 계정에 존재하고 VPC 인프라 대시보드에 나열되지 않으므로 보안 그룹을 만들어 작업자 노드 인스턴스에 적용할 수 없습니다. 기존 kube-<clusterID> 보안 그룹만 수정할 수 있습니다.
로깅 및 모니터링
4.15 이상 클러스터에서 로깅 및 모니터링을 설정할 때 클러스터에 로깅 에이전트를 설치할 때 개인 서비스 엔드포인트를 사용해야 합니다. 공용 엔드포인트가 사용되는 경우 로그 데이터가 저장되지 않습니다.
RHCOS 작업자 노드로 클러스터 모니터링
모니터링 에이전트는 운영 체제의 커널 헤더에 의존하지만 RHCOS에는 커널 헤더가 없습니다. 이 시나리오에서 에이전트는 sysdig.com 에 다시 도달하여 사전 컴파일된 에이전트를 사용합니다. 공용 네트워크에 액세스할 수 없는 클러스터에서는 이 프로세스가 실패합니다. eBPF 이제 새 Sysdig 배포에 대해 기본적으로 사용하도록 설정됩니다. 그러나 기존 클러스터에서 문제가 발생하는 경우 eBPF 이 활성화되어 있는지 확인하고 필요한 경우 활성화하세요. 또는 아웃바운드 트래픽을 허용하거나 에어 갭이 있는 환경에 에이전트를 설치하는 방법에 대한 Sysdig 설명서를 참조하세요.
VPC 클러스터 할당량
다른 보안 그룹을 소스 또는 대상으로 대상 지정할 수 있는 최대 15개의 규칙이 있습니다. 기본적으로 Red Hat OpenShift on IBM Cloud 는 VPC의 각 클러스터에 대해 kube-<clusterID> 보안 그룹을 대상으로 하는 규칙 1개를 적용합니다. 이 할당량으로 인해 지정된 VPC에서 15개의 클러스터만 작성할 수 있습니다. 자세한 정보는 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 주소를 바인드해야 합니다.