Red Hat OpenShift on IBM Cloud에 대한 보안

내 API 서버에 대한 접근 권한은 어떻게 부여되나요?

기본적으로 API 서버에 대한 액세스 권한이 부여되기 전에는 Kubernetes에서 모든 요청이 여러 단계를 거쳐야 합니다.

인증

등록된 사용자 또는 서비스 계정의 ID를 유효성 검증합니다.

권한

원하는 클러스터 구성요소만 액세스하고 작동할 수 있도록 인증된 사용자 및 서비스 계정의 권한을 제한합니다.

허가 제어

Red Hat OpenShift API 서버에서 처리하기 전에 요청을 유효성 검증하거나 변형합니다. Kubernetes 의 많은 기능은 제대로 작동하기 위해 어드미션 컨트롤러가 필요합니다.

Red Hat OpenShift on IBM Cloud 는 API 서버와 etcd 데이터 저장소를 보호하기 위해 어떤 조치를 취합니까?

다음 이미지는 Kubernetes 마스터와 작업자 노드 간에 인증, 권한 부여, 허가 제어 및 보안 연결을 처리하는 기본 클러스터 보안 설정을 보여줍니다.

Red Hat OpenShift API 서버 및 etcd의 다음 보안 기능을 검토하십시오.

전체 관리되는 전용 Red Hat OpenShift 마스터

Red Hat OpenShift on IBM Cloud의 모든 클러스터는 IBM에서 IBM 소유 Red Hat OpenShift 계정으로 관리하는 전용 IBM Cloud 마스터에 의해 제어됩니다. Red Hat OpenShift 마스터는 다른 IBM 고객과 공유하지 않는 다음의 전용 컴포넌트로 설정됩니다.

• etcd 데이터 저장소: Services, Deployments, Pods과 같은 클러스터의 모든 Kubernetes 리소스를 저장합니다. Kubernetes ConfigMaps 및 Secrets은 팟(Pod)에서 실행되는 앱에서 사용할 수 있도록 키 값 쌍으로 저장되는 앱 데이터입니다. etcd의 데이터는 Red Hat OpenShift 마스터의 로컬 디스크에 저장되며 IBM Cloud Object Storage에 백업됩니다. 데이터는 IBM Cloud Object Storage로 전송 중 및 저장 중에 암호화됩니다. 클러스터에 대한 IBM Key Protect 암호화를 사용으로 설정하여 Red Hat OpenShift 마스터의 로컬 디스크에 있는 etcd 데이터에 대한 암호화를 사용으로 설정하도록 선택할 수 있습니다. etcd 데이터가 팟(Pod)에 전송될 때 데이터는 데이터 보호와 무결성을 보장하기 위해 TLS를 통해 암호화됩니다.
• openshift-api: 작업자 노드에서 Red Hat OpenShift 마스터로의 모든 클러스터 관리 요청에 대한 기본 시작점 역할을 합니다. API 서버는 팟(Pod) 또는 서비스 등의 클러스터 리소스의 상태를 변경하는 요청을 유효성 검증하고 처리하며, 이 상태를 etcd 데이터 저장소에 저장합니다.
• openshift-controller: 새로 작성된 팟(Pod)을 감시하고 용량, 성능 요구사항, 정책 제한조건, 반친화성 스펙 및 워크로드 요구사항을 기반으로 이를 배치할 위치를 결정합니다. 요구사항과 일치하는 작업자 노드를 찾을 수 없으면 팟(Pod)이 클러스터에 배치되지 않습니다. 제어기는 복제본 세트 등의 클러스터 리소스의 상태를 감시합니다. 리소스의 상태가 변경되는 경우(예: 복제본 세트의 팟(Pod)이 작동 중지됨), 제어기 관리자는 정정 조치를 시작하여 필수 상태를 얻습니다.
• cloud-controller-manager: 클라우드 제어기 관리자는 클라우드 제공자별 컴포넌트(예: IBM Cloud 로드 밸런서)를 관리합니다.
• Konnectivity: Red Hat OpenShift on IBM Cloud- 모든 Red Hat OpenShift 마스터에서 워커 노드로의 통신을 위한 보안 네트워크 연결성을 제공하는 전용 구성 요소. Konnectivity 서버는 Konnectivity 에이전트와 함께 작동하여 마스터를 워커 노드에 안전하게 연결합니다. 이 연결은 팟(Pod) 및 서비스에 대한 apiserver proxy 요청과 kubelet에 대한 oc exec, attach 및 logs 요청을 지원합니다. 작업자 노드에서 마스터로의 연결은 TLS 인증서로 자동으로 보안이 설정됩니다.

IBM 사이트 신뢰성 엔지니어(SRE)에 의한 지속적 모니터링

Red Hat OpenShift 마스터(모든 마스터 컴포넌트, 컴퓨팅, 네트워킹 및 스토리지 리소스 포함)는 IBM 사이트 신뢰성 엔지니어(SRE)에 의해 지속적으로 모니터됩니다. SRE는 최신 보안 표준을 적용하고, 악성 활동을 발견하고 교정하며 Red Hat OpenShift on IBM Cloud의 신뢰성 및 가용성을 보장하기 위해 작업을 수행합니다.

CIS Kubernetes 마스터 벤치마크

Red Hat OpenShift on IBM Cloud를 구성하기 위해 IBM 엔지니어는 CIS(Center of Internet Security)에서 공개하는 Kubernetes 마스터 벤치마크의 관련 사이버 보안 사례를 따릅니다. 클러스터 마스터 및 모든 작업자 노드는 벤치마크를 충족하는 이미지와 함께 배치됩니다.

TLS를 통한 보안 통신

Red Hat OpenShift on IBM Cloud를 사용하려면 인증 정보를 사용한 서비스의 인증이 필요합니다. 사용자가 인증되면 Red Hat OpenShift on IBM Cloud는 작업자 노드와 Red Hat OpenShift 마스터 간의 엔드-투-엔드 보안 통신을 보장할 수 있도록 Red Hat OpenShift API 서버 및 etcd 데이터 저장소와의 양방향 통신을 암호화하는 TLS 인증서를 생성합니다. 이러한 인증서는 클러스터 간에 또는 Red Hat OpenShift 마스터 컴포넌트 간에 절대 공유되지 않습니다.

작업자 노드에 대한 연결

Kubernetes가 https 프로토콜을 사용하여 마스터 및 작업자 노드 간의 통신을 보호하지만, 기본적으로 작업자 노드에서는 인증이 제공되지 않습니다. 이 통신을 보호하기 위해, Red Hat OpenShift on IBM Cloud 은 클러스터 생성 시 Red Hat OpenShift 마스터와 워커 노드 간에 Konnectivity 연결을 자동으로 설정합니다.

세분화된 액세스 제어

계정 관리자는 IBM Cloud IAM(Identity and Access Management)을 사용하여 다른 사용자에게 Red Hat OpenShift on IBM Cloud에 대한 액세스 권한을 부여할 수 있습니다. IBM Cloud IAM은 IBM Cloud 플랫폼, Red Hat OpenShift on IBM Cloud 및 계정의 모든 리소스에 대한 보안 인증을 제공합니다. 리소스에 액세스할 수 있는 사용자를 제한하고 정당한 권한의 악용으로 초래할 수 있는 손해를 줄이기 위해서는 적절한 사용자 역할 및 권한을 부여하는 것이 중요합니다. 사용자가 수행할 수 있는 조치 세트를 판별하는 다음의 사전 정의된 사용자 역할에서 선택할 수 있습니다.

• 플랫폼 액세스 역할: 사용자가 Red Hat OpenShift on IBM Cloud에서 수행할 수 있는 클러스터 및 작업자 노드 관리 관련 조치를 판별합니다. 플랫폼 액세스 역할은 또한 사용자에게 basic-users 및 self-provisioners RBAC 역할을 지정합니다. 이러한 RBAC 역할을 사용하면 클러스터 내에 애플리케이션 관리( Red Hat OpenShift ) 프로젝트를 생성할 수 있으며, 해당 프로젝트 내에서 애플리케이션 및 기타 애플리케이션 관리 리소스( Kubernetes )를 배포할 수 있습니다. 프로젝트 작성자로서 사용자에게 프로젝트에 대한 admin RBAC 역할이 자동으로 지정되므로 프로젝트에서 배치하고 실행할 항목을 완전히 제어할 수 있습니다. 그러나 이러한 RBAC 역할은 다른 Red Hat OpenShift 프로젝트에 대한 액세스 권한을 부여하지 않습니다. 다른 Red Hat OpenShift 프로젝트를 보고 액세스하려면 IAM에서 적절한 서비스 액세스 역할이 지정되어야 합니다.
• 서비스 액세스 역할: 사용자에게 할당된 RBAC 역할 ( Kubernetes )과 사용자가 Red Hat OpenShift API 서버에 대해 실행할 수 있는 작업을 결정합니다. 플랫폼 액세스 역할이 지정된 basic-users 및 self-provisioners RBAC 역할이 있으면 자체 Red Hat OpenShift 프로젝트를 작성하고 관리할 수 있지만 서비스 액세스 역할이 지정될 때까지 다른 Red Hat OpenShift 프로젝트를 보거나 액세스하거나 작업할 수 없습니다. 사용자에게 할당된 RBAC 역할 및 관련 권한에 대한 자세한 내용은 IAM 서비스 액세스 역할을 참조하십시오.
• 클래식 인프라: 클래식 인프라 리소스에 대한 액세스를 가능하게 합니다. 클래식 인프라 역할에 의해 허용되는 조치의 예를 들면 클러스터 작업자 노드의 세부사항 보기, 네트워킹 및 스토리지 리소스 편집 등이 있습니다.
• VPC 인프라: VPC 인프라 리소스에 대한 액세스를 사용으로 설정합니다. VPC 인프라 역할로 허용되는 조치 예로 VPC 작성, 서브넷 추가, 유동 IP 주소 변경 및 VPC 블록 스토리지 인스턴스 작성을 들 수 있습니다.

클러스터의 액세스 제어에 대한 자세한 정보는 클러스터 액세스 지정을 참조하십시오.

승인 제어기

허가 제어기는 Kubernetes 및 Red Hat OpenShift on IBM Cloud의 특정 기능을 위해 구현되었습니다. 허가 제어기를 사용하면 클러스터의 특정 조치가 허용되는지 여부를 판별하는 클러스터의 정책을 설정할 수 있습니다. 이 정책에서는 사용자가 조치를 수행할 수 없을 때의 조건을 지정할 수 있습니다(이 조치가 RBAC 역할을 사용하여 사용자에게 지정된 일반 권한의 일부인 경우에도). 따라서 허가 제어기는 API 요청이 Red Hat OpenShift API 서버에서 처리되기 전에 클러스터에 대한 추가 보안 계층을 제공할 수 있습니다.

클러스터를 생성할 때, Red Hat OpenShift on IBM Cloud 은 기본 Kubernetes 어드미션 컨트롤러를 Red Hat OpenShift 마스터에 특정 순서로 자동 설치하며, 이는 사용자가 변경할 수 없습니다. 구성 요소 참조 정보에서 클러스터 버전에 따른 기본 액세스 컨트롤러의 순서를 검토하십시오.

클러스터에 자체 어드미션 컨트롤러를 설치하거나 선택적 어드미션 컨트롤러(예: Portieris )를 선택할 수 있습니다. Portieris를 사용하면 서명되지 않은 이미지로부터 컨테이너 배치를 차단할 수 있습니다.

수동으로 허가 제어기를 설치했으며 이를 더 이상 사용하지 않으려면 반드시 이를 완전히 제거해야 합니다. 허가 제어기가 완전히 제거되지 않은 경우, 이는 사용자가 클러스터에서 수행하고자 하는 모든 조치를 차단할 수 있습니다.

API 서버 보안을 강화하기 위해 무엇을 더 할 수 있을까요?

여러 가지 방법으로 클러스터 마스터에 대한 네트워크 연결을 제한할 수 있습니다

• 프라이빗 클라우드 서비스 엔드포인트만 사용 설정합니다: 공용 서비스 엔드포인트는 기존 OpenShift 클러스터에만 필요합니다. 모든 VPC 클러스터에 대해 비활성화할 수 있습니다. 계정에 VRF 및 서비스 엔드포인트가 사용 설정되어 있는 경우 기존 Kubernetes 클러스터에 대해서도 비활성화할 수 있습니다. 이렇게 하면 공용 네트워크에 대한 공격으로부터 클러스터 마스터를 보호할 수 있습니다.
• 컨텍스트 기반 제한을 사용 설정합니다: 컨텍스트 기반 제한(CBR)을 사용하여 클러스터의 비공개 및 공용 서비스 엔드포인트에 대한 네트워크 액세스를 보호할 수 있습니다. CBR 규칙의 서브넷에서 시작된 클러스터 마스터에 대한 승인된 요청만 허용됩니다. 자세한 내용은 컨텍스트 기반 제한 사용하기를 참조하세요.

작업자 노드의 소유자는 누구이며, 제가 이를 보호할 책임이 있나요?

작업자 노드의 소유권은 작성된 클러스터의 유형 및 선택한 인프라 제공자에 따라 다릅니다.

• 클래식 클러스터: 워커 노드가 귀하의 IBM Cloud 계정에 프로비저닝됩니다. 작업자 노드는 사용자 전용이며 사용자는 작업자 노드 OS 및 IBM Cloud Kubernetes Service 컴포넌트가 최신 보안 업데이트와 패치를 적용하도록 보장하기 위해 작업자 노드에 대한 시기 적절한 업데이트를 요청할 책임이 있습니다.
• VPC 클러스터: 악성 활동 모니터링 및 보안 업데이트 적용을 위해 IBM 소유의 IBM Cloud 계정에 워커 노드가 프로비저닝됩니다. VPC 대시보드를 사용하여 작업자 노드에 액세스할 수 없습니다. 하지만, IBM Cloud Kubernetes Service 콘솔, CLI 또는 API를 사용하여 작업자 노드를 관리할 수 있습니다. 작업자 노드를 작성하는 가상 머신은 사용자 전용이며 사용자는 작업 노드 OS 및 IBM Cloud Kubernetes Service 컴포넌트가 최신 보안 업데이트 및 패치를 적용하도록 적시에 요청할 책임이 있습니다.

자세한 정보는 Red Hat OpenShift on IBM Cloud 사용 시 사용자의 책임을 참조하십시오.

ibmcloud oc worker update 명령을 주기적(예: 매월)으로 사용하여 운영 체제에 업데이트와 보안 패치를 배치하고 작업자 노드가 실행하는 Red Hat OpenShift 버전을 업데이트하십시오. 업데이트를 사용할 수 있는 경우에는 IBM Cloud 콘솔 또는 CLI에서 마스터 및 작업자 노드에 대한 정보를 볼 때 알림을 받습니다(예: ibmcloud oc clusters ls 또는 ibmcloud oc workers ls --cluster <cluster_name> 명령을 사용하여). 작업자 노드 업데이트는 IBM이 최신 보안 패치를 포함하는 전체 작업자 노드 이미지로 제공합니다. 업데이트를 적용하려면 새 이미지를 사용하여 작업자 노드를 다시 이미징하고 다시 로드해야 합니다. 루트 사용자의 키는 작업자 노드가 다시 로드되면 자동으로 순환됩니다.

내 워커 노드 설정은 어떻게 되어 있나요?

다음의 이미지는 악성 공격으로부터 작업자 노드를 보호하기 위해 모든 작업자 노드에 대해 설정된 컴포넌트를 보여줍니다.

이미지에는 작업자 노드와의 양방향 엔드-투-엔드 보안 통신을 보장하는 컴포넌트가 포함되지 않습니다. 자세한 정보는 네트워크 보안을 참조하십시오.

CIS-준수 이미지

모든 작업자 노드는 인터넷 보안 센터( CIS )에서 공개하는 벤치마크를 구현하는 운영 체제로 설정됩니다. 시스템 소유자 또는 사용자는 이 운영 체제를 다른 운영 체제로 변경할 수 없습니다. 현재 OS 버전을 확인하려면 다음 명령을 실행하십시오 oc get nodes -o wide. IBM은 내부 및 외부 보안 자문 팀과 공동 작업하여 잠재적 보안 준수 취약점을 해결합니다. 운영 체제에 대한 보안 업데이트와 패치는 Red Hat OpenShift on IBM Cloud를 통해 사용할 수 있으며, 작업자 노드의 보안을 유지하기 위해 사용자에 의해 설치되어야 합니다.

Red Hat OpenShift on IBM Cloud 워커 노드에 Linux 커널을 사용합니다. Red Hat OpenShift on IBM Cloud에서 Linux 배포판을 기반으로 컨테이너를 실행할 수 있습니다. 컨테이너 이미지 공급업체에 문의하여 해당 컨테이너 이미지가 커널에서 실행 가능한지 확인하십시오.

사이트 신뢰성 엔지니어(SRE)에 의한 지속적 모니터링

작업자 노드에 설치된 이미지는 취약성 및 보안 규제 준수 문제를 발견하기 위해 IBM 사이트 신뢰성 엔지니어(SRE)에 의해 지속적으로 모니터링됩니다. SRE는 취약성에 대처하기 위해 작업자 노드를 위한 보안 패치 및 수정팩을 작성합니다. 작업자 노드와 해당 노드에서 실행하는 애플리케이션의 안전한 환경을 보장하기 위해 패치가 제공되는 즉시 적용하시기 바랍니다.

CIS Kubernetes 작업자 노드 벤치마크

Red Hat OpenShift on IBM Cloud 를 구성하기 위해 IBM 엔지니어들은 인터넷 보안 센터(CIS, CIS )에서 발행한 Kubernetes 워커 노드 벤치마크의 관련 사이버 보안 관행을 따릅니다. CIS Kubernetes 벤치마크 및 Red Hat OpenShift 벤치마크 표준에 대해 작업자 노드의 규제 준수를 검토할 수 있습니다.

컴퓨팅 격리

작업자 노드는 한 클러스터 전용이며, 다른 클러스터의 워크로드를 호스팅하지 않습니다. 클래식 클러스터를 생성할 때, 워커 노드를 물리적 머신(베어 메탈)으로 프로비저닝하거나 공유 또는 전용 물리적 하드웨어에서 실행되는 가상 머신으로 프로비저닝할 수 있습니다. VPC 클러스터의 작업자 노드는 공유 인프라에서 가상 머신으로만 프로비저닝할 수 있습니다.

클래식에서의 베어메탈 배치 옵션

표준 클래식 클러스터를 작성하는 경우, 베어메탈 실제 서버(가상 서버 인스턴스 대신)에서 작업자 노드의 프로비저닝을 선택할 수 있습니다. 베어메탈 머신을 사용하면 메모리 또는 CPU 등의 컴퓨팅 호스트에 대한 추가적인 제어 권한이 있습니다. 이 설정은 호스트에서 실행되는 가상 머신에 실제 리소스를 할당하는 가상 머신 하이퍼바이저를 제거합니다. 대신, 모든 베어메탈 머신의 리소스가 작업자 전용으로만 사용되므로 리소스를 공유하거나 성능을 저하시키는 "시끄러운 이웃(noisy neighbors)" 문제를 신경쓰지 않아도 됩니다. 베어메탈 서버는 클러스터 사용에 사용 가능한 모든 리소스를 포함하여 사용자에게만 전용으로 제공됩니다.

암호화된 디스크

기본적으로 모든 작업자 노드는 2개의 로컬 SSD, AES 256비트 암호화된 데이터 파티션으로 프로비저닝됩니다. 첫 번째 파티션에는 작업자 노드의 부팅에 사용되며 암호화되지 않은 커널 이미지가 포함되어 있습니다. 두 번째 파티션은 컨테이너 파일 시스템을 보유하며 LUKS 암호화 키를 사용하여 잠금 해제됩니다. 클러스터의 각 작업자 노드에는 Red Hat OpenShift on IBM Cloud에 의해 관리되는 자체 고유 LUKS 암호화 키가 있습니다. 클러스터를 작성하거나 기존 클러스터에 작업자 노드를 추가하는 경우, 키를 안전하게 가져온 다음 암호화 디스크가 잠금 해제된 후에 버려집니다. 암호화는 디스크 I/O 성능에 영향을 줄 수 있습니다. 고성능 디스크 I/O가 필요한 워크로드의 경우, 암호화를 끌지 여부를 결정하는 데 도움이 되도록 암호화가 사용된 클러스터와 사용되지 않은 클러스터를 둘 다 테스트하십시오.

SELinux

모든 워커 노드는 부트스트래핑 중에 워커 노드에 로드되는 SELinux(Security-Enhanced Linux) 프로필에 의해 적용되는 보안 및 액세스 정책으로 설정됩니다. 시스템 소유자 또는 사용자는 SELinux 프로파일을 변경할 수 없습니다.

SSH 사용 안함

기본적으로, 악성 공격으로부터 클러스터를 보호하기 위해 SSH 액세스는 작업자 노드에서 사용 안함으로 설정됩니다. SSH 액세스가 사용 안함으로 설정되는 경우, 클러스터에 대한 액세스는 Red Hat OpenShift API 서버틀 통해 강제 실행됩니다. Red Hat OpenShift API 서버에서는 요청이 클러스터에서 실행되기 전에 인증, 권한 부여 및 허가 제어 모듈에 설정된 정책과 비교하여 모든 요청을 검사해야 합니다.

표준 클러스터를 보유하고 있으며 워커 노드에 더 많은 기능을 설치하려는 경우, Red Hat OpenShift on IBM Cloud 에서 제공하는 애드온 중에서 선택하거나 모든 워커 노드에서 실행하려는 모든 항목에 대해 Kubernetes 데몬 세트를 사용할 수 있습니다. 실행해야 하는 일회성 작업에는 Kubernetes 작업을 사용하십시오.

클래식 클러스터의 네트워크 세그먼트화 및 개인정보처리방침

네트워크에 대한 액세스 권한이 부여될 때 사용자가 입힐 수 있는 손상의 범위를 제한하고 네트워크를 보호하려면, 워크로드가 가급적 분리되어 있으며 공용으로 노출된 앱과 작업자 노드의 수에 제한이 있는지 확인해야 합니다.

클래식 클러스터에 대해 기본적으로 허용되는 네트워크 트래픽은 무엇입니까?

모든 컨테이너는 클러스터 작성 중에 모든 작업자 노드에서 구성된 사전 정의된 Calico 네트워크 정책 설정에 의해 보호됩니다. 기본적으로, 모든 아웃바운드 네트워크 트래픽이 모든 작업자 노드에 대해 허용됩니다. 인바운드 네트워크 트래픽은 다음 예외를 제외하고 차단됩니다.

• NodePort: 기본적으로 KubernetesNodePort 범위가 열려 있으므로 NodePort 서비스를 통해 애플리케이션을 노출할 수 있습니다. 클러스터의 NodePort에 대한 인바운드 네트워크 트래픽을 차단하려면 NLB 또는 NodePort 서비스에 대한 인바운드 트래픽 제어를 참조하십시오.
• IBM 모니터링 포트: 기본적으로 IBM은 네트워크 트래픽을 모니터하고 Red Hat OpenShift 마스터에 대한 보안 업데이트를 자동으로 설치할 수 있도록 클러스터에서 몇 개의 포트를 엽니다.

Red Hat OpenShift 마스터에서 워커 노드의 kubelet에 대한 액세스는 Konnectivity 터널을 통해 보안 처리됩니다. 자세한 정보는 Red Hat OpenShift on IBM Cloud 아키텍처를 참조하십시오.

네트워크 세그멘테이션이란 무엇이며, 클래식 클러스터에 어떻게 설정할 수 있나요?

네트워크 세그먼트화는 네트워크를 다중 하위 네트워크로 분할하기 위한 접근 방식을 말합니다. 사용자는 조직의 특정 그룹이 액세스하는 앱 및 관련 데이터를 그룹화할 수 있습니다. 하나의 서브네트워크에서 실행되는 앱은 다른 서브네트워크의 앱을 보거나 이에 액세스할 수 없습니다. 또한 네트워크 세그먼트화는 내부자 또는 제3자 소프트웨어에 제공되는 액세스를 제한하고 악성 활동의 범위를 제한할 수도 있습니다.

Red Hat OpenShift on IBM Cloud는 작업자 노드에 대한 고품질 네트워크 성능 및 네트워크 격리를 보장하는 IBM Cloud VLAN을 제공합니다. VLAN은 동일한 실제 회선에 연결된 것처럼 작업자 노드 및 팟(Pod)의 그룹을 구성합니다. VLAN은 IBM Cloud 계정 전용이며 IBM 고객 간에 공유되지 않습니다. 클래식 클러스터에서 클러스터용 다중 VLAN, 동일한 VLAN의 다중 서브넷 또는 다중 구역 클래식 클러스터가 있는 경우에는 작업자 노드가 사설 네트워크에서 서로 간에 통신할 수 있도록 IBM Cloud 인프라 계정에 대해 VRF(Virtual Router Function)를 사용으로 설정해야 합니다. VRF를 사용으로 설정하려면 VRF 사용을 참조하십시오. VRF가 이미 사용으로 설정되었는지 확인하려면 ibmcloud account show 명령을 사용하십시오. VRF를 사용할 수 없거나 사용하지 않으려면 VLAN Spanning을 사용으로 설정하십시오. 이 작업을 수행하려면 네트워크 > 네트워크 VLAN 스패닝 인프라 관리 권한이 필요합니다. 또는 계정 소유자에게 권한을 활성화해 달라고 요청할 수 있습니다. VLAN 스패닝이 이미 활성화되었는지 확인하려면 다음 ibmcloud oc vlan spanning get --region <region>명령을 사용하십시오.

계정에 대해 VRF 또는 VLAN Spanning을 사용으로 설정하면 클러스터에 대한 네트워크 세그먼트화가 제거됩니다.

사용자 계정에 대해 VRF 또는 VLAN Spanning이 사용으로 설정된 경우 네트워크 세그먼트멘테이션을 구현하는 방법에 대한 옵션을 보려면 다음 표를 검토하십시오.

클래식 클러스터의 외부 공격 표면을 줄이기 위해 제가 할 수 있는 다른 방법은 무엇인가요?

사용자가 공용으로 노출하는 앱 또는 작업자 노드가 많을수록 외부의 악성 공격을 막기 위해 더 많은 단계를 취해야 합니다. 앱 및 작업자 노드를 개인용으로 유지하는 방법에 대한 옵션을 찾으려면 다음 표를 검토하십시오.

내 클러스터를 온프레미스 데이터 센터에 연결하려면 어떻게 해야 하나요?

워커 노드와 앱을 온프레미스 데이터 센터에 연결하려면 Virtual Router Appliance 또는 포티게이트 보안 어플라이언스를 구성할 수 있습니다.

VPC 클러스터의 네트워크 세그먼트화 및 개인정보처리방침

네트워크에 대한 액세스 권한이 부여될 때 사용자가 입힐 수 있는 손상의 범위를 제한하고 네트워크를 보호하려면, 워크로드가 가급적 분리되어 있으며 공용으로 노출된 앱과 작업자 노드의 수에 제한이 있는지 확인해야 합니다.

기본적으로 내 VPC 클러스터에 허용되는 네트워크 트래픽은 무엇입니까?

기본적으로 작업자 노드는 사설 네트워크의 VPC 서브넷에만 연결되며 이 노드에는 공용 네트워크 인터페이스가 없습니다. 작업자 노드에 대한 모든 공인 접속이 차단되었습니다. 작업자 노드의 공용 유출은 작업자가 퍼블릭 게이트웨이가 있는 VPC 서브넷에 연결된 경우에만 허용됩니다.

VPC의 사설 네트워크에 연결하지 않고 웹 콘솔 또는 OperatorHub와 같은 기본 Red Hat OpenShift 컴포넌트에 액세스하려면 작업자 노드가 배치된 VPC 서브넷에 퍼블릭 게이트웨이를 연결해야 합니다. 모든 유출이 연결된 퍼블릭 게이트웨이가 있는 서브넷의 작업자 노드에 대해 허용되지만, 모든 유입은 여전히 차단됩니다.

인터넷에서 트래픽 요청을 수신해야 하는 클러스터에 앱을 배치하는 경우 앱을 노출하기 위해 VPC 로드 밸런서를 작성할 수 있습니다. 앱으로의 유입 네트워크 트래픽을 허용하려면 수신할 유입 네트워크 트래픽의 VPC 로드 밸런서를 구성해야 합니다.

보안 그룹은 기본적으로 VPC 인스턴스와 VPC ALB 및 NLB에 적용됩니다. 자세한 내용은 기본 클러스터 VPC 네트워킹을 통한 보안 이해하기 및 VPC 보안 그룹 만들기 및 관리하기를 참조하세요.

네트워크 세그멘테이션이란 무엇이며, VPC 클러스터에 이를 설정하는 방법은 무엇인가요?

네트워크 세그먼트화는 네트워크를 다중 하위 네트워크로 분할하기 위한 접근 방식을 말합니다. 사용자는 조직의 특정 그룹이 액세스하는 앱 및 관련 데이터를 그룹화할 수 있습니다. 하나의 서브네트워크에서 실행되는 앱은 다른 서브네트워크의 앱을 보거나 이에 액세스할 수 없습니다. 또한 네트워크 세그먼트화는 내부자 또는 제3자 소프트웨어에 제공되는 액세스를 제한하고 악성 활동의 범위를 제한할 수도 있습니다.

Red Hat OpenShift on IBM Cloud는 작업자 노드에 대한 고품질 네트워크 성능과 네트워크 격리를 보장하는 IBM Cloud VPC 서브넷을 제공합니다. VPC 서브넷은 지정된 사설 IP 주소 범위(CIDR 블록)로 구성되며 동일한 실제 회선에 연결된 것처럼 작업자 노드 및 팟(Pod)의 그룹을 구성합니다. VPC 서브넷은 IBM Cloud 계정 전용이며 IBM 고객 간에 공유되지 않습니다.

VPC 서브넷은 클러스터 내 작업자 노드 간에 연결을 위한 채널을 제공합니다. 동일한 VPC의 사설 서브넷에 연결된 시스템은 작업자와 통신할 수 있습니다. 예를 들어, 하나의 VPC에 있는 모든 서브넷은 기본 제공 VPC 라우터를 사용하는 사설 계층 3 라우팅을 통해 통신할 수 있습니다. 클러스터의 통신이 필요하지 않으면 개별 VPC에서 클러스터를 작성하여 최상의 네트워크 세그먼테이션을 수행할 수 있습니다. 서로 통신해야 하는 다중 클러스터가 있는 경우 동일한 VPC에 클러스터를 작성할 수 있습니다. 해당 VPC의 여러 클러스터가 1개 VPC 내의 서브넷을 공유할 수 있지만, 사용자는 1개 VPC 내의 클러스터에 대해 서로 다른 서브넷을 사용함으로써 보다 우수한 네트워크 세그먼트화를 수행할 수 있습니다.

사용자 계정의 VPC 서브넷 간에 추가로 사설 네트워크 세그먼트화를 수행하기 위해 사용자는 VPC 액세스 제어 목록(ACL)으로 사용자 정의 네트워크 정책을 설정할 수 있습니다. VPC를 작성할 때 기본 ACL은 VPC에 해당하는 allow-all-network-acl-<VPC_ID> 형식으로 작성됩니다. 기본적으로 VPC에서 작성하는 서브넷은 이 ACL에 연결됩니다. ACL에는 동일 VPC에서 서브넷의 임의의 시스템과 서브넷의 작업자 노드 간에 모든 트래픽을 허용하는 아웃바운드 규칙과 인바운드 규칙이 포함됩니다. VPC 서브넷의 작업자 노드에 허용되는 사설 네트워크 트래픽을 지정하고자 하는 경우 VPC의 각 서브넷마다 사용자 정의 ACL을 작성할 수 있습니다. 예를 들어, 클러스터의 작동에 필요한 통신을 허용하면서도 클러스터의 대부분의 인바운드 및 아웃바운드 네트워크 사설 트래픽을 차단하기 위한 ACL 규칙 세트를 작성할 수 있습니다.

VPC 클러스터의 외부 공격 표면을 줄이기 위해 제가 할 수 있는 다른 방법은 무엇인가요?

사용자가 공용으로 노출하는 앱 또는 작업자 노드가 많을수록 외부의 악성 공격을 막기 위해 더 많은 단계를 취해야 합니다. 앱 및 작업자 노드를 개인용으로 유지하는 방법에 대한 옵션을 찾으려면 다음 표를 검토하십시오.

작업자 노드가 연결될 네트워크에 따라 VPN 솔루션을 선택할 수 있습니다.

라우트를 사용하여 안전하게 앱 노출

인터넷에서 들어오는 네트워크 트래픽을 허용하려면 라우트를 사용하여 애플리케이션을 노출할 수 있습니다.

모든 Red Hat OpenShift 클러스터에는 고유한 도메인 이름이 할당되고 TLS 인증서로 보호되는 Red Hat OpenShift 라우터가 자동으로 설정됩니다. 라우트를 사용하여 앱을 노출하면, 앱에 Red Hat OpenShift 라우터의 URL이 지정됩니다.

앱에 대한 라우트를 작성할 때 보안(HTTPS) 또는 비보안(HTTP) 라우트를 작성하도록 결정할 수 있습니다. 보안 라우트의 경우, TLS 종료를 구현할 위치(예: 라우터나 팟(Pod))를 결정할 수 있습니다. 자세한 정보는 라우트로 앱 노출을 참조하십시오.

LoadBalancer 및 Ingress 서비스를 사용하여 안전하게 앱 노출

네트워크 로드 밸런서(NLB) 및 Ingress 애플리케이션 로드 밸런서(ALB) 네트워킹 서비스를 사용하여 앱을 공용 인터넷 또는 외부 사설 네트워크에 연결할 수 있습니다. 백엔드 앱 보안 요구사항을 충족시키는 데 사용할 수 있는 NLB 및 ALB에 대해 다음의 선택적 설정을 검토하거나, 클러스터를 통해 이동할 때 트래픽을 암호화하십시오.

보안 그룹을 사용하여 클러스터의 네트워크 트래픽을 관리할 수 있나요?

클래식 클러스터: IBM Cloud 보안 그룹은 하이퍼바이저 레벨에서 트래픽을 필터링하기 위해 단일 가상 서버의 네트워크 인터페이스에 적용됩니다. 각 작업자 노드에 대한 트래픽을 관리하려는 경우 보안 그룹을 사용할 수 있습니다. 보안 그룹을 작성하는 경우에는 NLB IP 주소를 관리하기 위해 Red Hat OpenShift on IBM Cloud에서 사용하는 VRRP 프로토콜을 허용해야 합니다. 클러스터의 모든 워커 노드에 걸쳐 트래픽을 균일하게 관리하려면 Calico 및 Kubernetes 정책을 사용하십시오.

VPC 클러스터: VPC 보안 그룹이 하이퍼바이저 레벨의 트래픽을 필터링하도록 단일 가상 서버의 네트워크 인스턴스에 적용됩니다. 클러스터에 대한 인바운드 및 아웃바운드 트래픽을 관리하기 위해 클러스터의 기본 보안 그룹에 인바운드 및 아웃바운드 규칙을 추가할 수 있습니다. 자세한 내용은 기본 클러스터 VPC 네트워킹을 통한 보안 이해하기 및 VPC 보안 그룹 만들기 및 관리하기를 참조하세요.

VPC 클러스터의 작업자 노드는 서비스 계정에 있지만 VPC 인프라 대시보드에는 나열되지 않으므로 보안 그룹을 작성하여 작업자 노드 인스턴스에 적용할 수 없습니다. 사용자를 위해 작성된 기존 보안 그룹만 수정할 수 있습니다.

LoadBalancer 와 Ingress 서비스에서 TLS 종료를 어떻게 수행할 수 있나요?

Ingress 서비스는 트래픽 플로우의 두 지점에서 TLS 종료를 제공합니다.

• 도착 시 패키지 해독: 기본적으로 Ingress ALB는 HTTP 네트워크 트래픽을 클러스터 내 애플리케이션으로 부하 분산합니다. 수신 HTTPS 연결도 로드 밸런싱하려면 네트워크 트래픽을 복호화하고 클러스터에 노출된 앱으로 복호화된 요청을 전달하도록 ALB를 구성할 수 있습니다. IBM 제공 Ingress 하위 도메인을 사용하는 경우에는 IBM 제공 TLS 인증서를 사용할 수 있습니다. 사용자 정의 도메인을 사용하는 경우에는 자체 TLS 인증서를 사용하여 TLS 종료를 관리할 수 있습니다.
• 업스트림 앱으로 전달하기 전에 패키지 재암호화: ALB는 트래픽을 앱으로 전달하기 전에 HTTPS 요청을 복호화합니다. HTTPS가 필요하며 해당 업스트림 앱으로 전달되기 전에 트래픽의 암호화가 필요한 앱이 있는 경우에는 ssl-services 어노테이션을 사용할 수 있습니다. 업스트림 앱이 TLS를 처리할 수 있는 경우에는 단방향 또는 상호 인증 TLS 시크릿에 포함된 인증서를 선택적으로 제공할 수 있습니다.

단일 테넌트 클러스터를 설정해야 할까요, 아니면 다중 테넌트 클러스터를 설정해야 할까요?

싱글 테넌트 클러스터에서는 클러스터에서 워크로드를 실행해야 하는 모든 사용자 그룹에 대해 하나의 클러스터를 작성합니다. 일반적으로, 이 팀은 클러스터를 관리하고 이를 알맞게 구성하며 보호해야 할 책임을 집니다. 멀티 테넌트 클러스터는 다중 프로젝트를 사용하여 테넌트 및 해당 워크로드를 격리합니다.

싱글 테넌트와 멀티 테넌트 클러스터 중에서의 결정은 클러스터에서 워크로드를 실행해야 하는 팀의 수, 이의 서비스 요구사항, 서비스의 크기 및 워크로드에 대해 달성할 격리 레벨에 따라 다릅니다.

각각 클러스터의 라이프사이클을 제어해야 하는 복잡한 서비스가 있는 많은 팀을 보유한 경우에는 싱글 테넌트 클러스터가 해당 옵션이 될 수 있습니다. 여기에는 클러스터가 업데이트되는 시점 또는 클러스터에 배치될 수 있는 리소스를 결정할 수 있는 자유가 포함됩니다. 또한 기타 테넌트가 손상되지 않고 권한 있는 팟(Pod)을 허용하도록 싱글 테넌트 클러스터를 구성할 수도 있습니다. 클러스터 관리에서는 배치에 대한 클러스터 용량과 보안을 보장할 수 있도록 깊은 Kubernetes, Red Hat OpenShift 및 인프라 지식이 요구된다는 점을 유념하십시오.

멀티 테넌트 클러스터는 Red Hat OpenShift 프로젝트를 사용하여 테넌트를 격리하고 일반적으로 테넌트 중 하나에 속하지 않는 별도의 팀에서 관리합니다. 클러스터에서 소형 워크로드를 실행해야 하는 여러 팀이 있는 경우 멀티 테넌트 클러스터는 옵션 중 하나가 될 수 있고, 다중 구역에서 고가용성인 싱글 테넌트 클러스터를 작성하면 사용자가 원하는 비용 절감 혜택을 얻을 수 없습니다. 멀티 테넌트 클러스터에서는 일반적으로 클러스터 관리 및 운용 인력이 덜 필요하지만, 필요한 격리 레벨이 제공되지 않고 다음 영역에서 복잡도가 더 추가될 수 있습니다.

• 액세스: 다중 프로젝트를 설정하는 경우 리소스 격리를 보장할 수 있도록 각 프로젝트에 대해 적절한 RBAC 정책을 구성해야 합니다. RBAC 정책은 복잡하며 깊은 Kubernetes 지식이 필요합니다.
• 권한 있는 팟(Pod): 멀티 테넌트 클러스터의 하나의 테넌트가 권한 있는 팟(Pod)을 실행해야 하는 경우 이 팟(Pod)은 클러스터의 다른 프로젝트에 액세스하거나 공유 컴퓨팅 호스트에 손상을 줄 수 있습니다. 권한 있는 팟(Pod)의 제어는 노력과 고도의 기술 전문성을 필요로 하는 복잡한 태스크입니다. SCC(Security Context Constraint)를 사용하여 테넌트가 클러스터에 배치할 수 있는 리소스를 제어하십시오.
• 네트워크 정책: 작업자 노드가 동일한 사설 네트워크에 연결되어 있으므로 팟(Pod)이 기타 네임스페이스의 팟(Pod)에 액세스할 수 없도록 엄격한 네트워크 정책이 올바른 위치에 있는지 확인해야 합니다.
• 컴퓨팅 리소스 제한: 클러스터 내에서 모든 팀이 서비스를 배포하고 애플리케이션을 실행하는 데 필요한 리소스를 확보할 수 있도록, 각 네임스페이스에 대해 리소스 할당량을 설정해야 합니다. 리소스 할당량은 배포 제약 조건을 결정합니다. 예를 들어 배포할 수 있는 애플리케이션 풀( Kubernetes )의 수, 해당 리소스가 소비할 수 있는 CPU 및 메모리 양 등이 포함됩니다. 할당량을 설정한 후에 사용자는 자체 배치의 리소스 요청 및 한계를 포함해야 합니다.
• 공유 클러스터 리소스: 하나의 클러스터에서 멀티 테넌트를 실행하는 경우, 일부 클러스터 리소스(예: Red Hat OpenShift 라우터, Ingress 애플리케이션 로드 밸런서(ALB)) 또는 사용 가능한 포터블 IP 주소)는 테넌트 간에 공유됩니다. 클러스터의 대형 서비스와 경쟁해야 하는 경우, 보다 소형의 서비스는 공유 리소스 사용에 어려움을 겪어야 할 수 있습니다.
• 업데이트: 한 번에 하나의 Red Hat OpenShift API 버전만 실행할 수 있습니다. 클러스터에서 실행되는 모든 앱은 앱을 소유하는 팀과 무관하게 현재 Red Hat OpenShift API 버전을 준수해야 합니다. 클러스터를 업데이트하려면 모든 팀이 새 Red Hat OpenShift API 버전으로 전환할 준비가 되었으며 앱이 이에 맞게 업데이트되었는지 확인해야 합니다. 또한 이는 개별 팀에게 자신이 실행할 Red Hat OpenShift API 버전에 대한 보다 약한 제어권이 있음을 의미합니다.
• 클러스터 설정의 변경: 클러스터 설정을 변경하거나 새 작업자 노드로 워크로드를 다시 스케줄하려는 경우에는 테넌트 간에 이러한 변경사항을 롤아웃해야 합니다. 이 롤아웃에서는 싱글 테넌트 클러스터에서보다 더 많은 조정과 테스트가 필요합니다.
• 통신 프로세스: 멀티 테넌트를 관리하는 경우, 클러스터에서 문제가 발생하거나 해당 서비스를 위해 더 많은 리소스를 필요로 할 때 이동할 위치를 테넌트가 파악할 수 있도록 통신 프로세스를 설정하는 것을 고려하십시오. 이 통신 프로세스에는 클러스터 설정이나 계획된 업데이트의 모든 변경사항에 대해 테넌트에 알리는 것도 포함됩니다.

싱글 테넌트 및 멀티 테넌트가 거의 동일한 비용으로 제공되지만 싱글 테넌트 클러스터는 멀티 테넌트의 클러스터의 프로젝트보다 더 높은 격리 레벨을 제공합니다. 워크로드 격리의 개선을 위해 싱글 테넌트 클러스터를 사용하십시오.

Kubernetes 네트워크 정책이 내부 네트워크 트래픽으로부터 팟(Pod)을 보호합니다. 예를 들어, 대부분 또는 모든 팟(Pod)이 특정 팟(Pod) 또는 서비스에 액세스할 필요가 없고 팟(Pod)이 기본적으로 해당 팟(Pod) 또는 서비스에 액세스할 수 없도록 하려면 해당 팟(Pod) 또는 서비스에 대한 Ingress 트래픽을 차단하는 Kubernetes 네트워크 정책을 작성할 수 있습니다. Kubernetes 네트워크 정책을 사용하면 서로 다른 네임스페이스의 팟(Pod)과 서비스가 통신하는 방법을 제어하여 네임스페이스 간의 워크로드 격리를 강제 실행할 수 있습니다.

포드 권한을 어떻게 제어할 수 있나요?

프로젝트 내에서 또는 프로젝트 간에 팟(Pod) 권한을 제어하기 위해 Red Hat OpenShift on IBM Cloud는 보안 컨텍스트 제한조건(SCC)을 사용합니다. 기본적으로 모든 클러스터는 클러스터 내 권한을 제한하기 위해 서비스 계정, 팟(Pod), 배치 또는 프로젝트에 지정할 수 있는 Red Hat OpenShift SCC 및 IBM 제공 SCC 세트로 설정되어 있습니다. SCC를 명시적으로 지정하지 않으면 팟(Pod)이 restricted SCC를 사용합니다. Red Hat OpenShift SCC는 커뮤니티 Kubernetes 클러스터의 기본 팟(Pod) 보안 정책보다 엄격합니다. 이 앱이 Red Hat OpenShift에서 실행될 수 있도록 커뮤니티 Kubernetes 클러스터에서 실행되는 앱을 수정해야 합니다. 자세한 정보는 보안 컨텍스트 제한조건 구성을 참조하십시오.

내 컨테이너를 보호하기 위해 또 무엇을 할 수 있나요?

특권 컨테이너의 수를 제한하십시오. 컨테이너는 기타 프로세스와 격리된 컴퓨팅 호스트에서 개별 Linux 프로세스로서 실행됩니다. 컨테이너 내부에서 사용자에게는 루트 액세스 권한이 있지만, 기타 Linux 프로세스, 호스트 파일 시스템 및 호스트 디바이스를 보호할 수 있도록 컨테이너 외부에서는 이 사용자의 권한이 제한됩니다. 일부 앱에서는 올바른 실행을 위한 고급 권한 또는 호스트 파일 시스템에 대한 액세스 권한이 필요합니다. 권한 모드에서 컨테이너를 실행하면 컴퓨팅 호스트에서 실행 중인 프로세스와 동일한 액세스 권한을 컨테이너에 허용할 수 있습니다.

권한 있는 컨테이너는 손상된 경우 클러스터와 기본 컴퓨팅 호스트에 상당한 피해를 줄 수 있음을 유념하십시오. 권한 모드에서 실행되는 컨테이너의 수를 제한해 보고, 앱이 고급 권한 없이 실행될 수 있도록 앱에 대한 구성의 변경을 고려하십시오.

클러스터에서 권한 있는 컨테이너가 실행되지 않도록 하려면 사용자 정의 보안 컨텍스트 제한조건 설정을 고려하십시오.

팟(Pod)에 OS 보안 설정 적용

기본 보안 컨텍스트 제약 조건을 사용자 정의하여 컨테이너 내에서 실행할 수 있는 사용자 ID 및 그룹 ID, 또는 볼륨 마운트 경로의 소유자 사용자 ID 및 그룹 ID를 제어할 수 있습니다. 특정 사용자 ID를 설정하면 최소 권한 모델을 쉽게 사용할 수 있습니다. 보안 컨텍스트가 사용자를 지정하지 않으면 Kubernetes가 컨테이너 이미지에 지정된 사용자를 자동으로 사용합니다. 자세한 정보는 보안 컨텍스트 제한조건 구성을 참조하십시오.

컨테이너에 대한 CPU 및 메모리 한계 설정

제대로 시작하고 실행을 지속하기 위해 모든 컨테이너에서는 특정 양의 CPU 및 메모리가 필요합니다. 컨테이너나 포드에 대해 리미트 범위를 정의하여 해당 리소스가 소비할 수 있는 CPU 및 메모리 양을 제한할 수 있습니다. CPU 및 메모리에 대한 한계가 설정되어 있지 않은 상태에서 컨테이너가 작동되는 경우, 컨테이너는 사용 가능한 모든 리소스를 사용합니다. 이러한 높은 리소스 이용량은 제대로 시작하거나 실행하기 위한 충분한 리소스가 없는 작업자 노드의 기타 컨테이너에 영향을 줄 수 있으며, 작업자 노드는 서비스 거부(DoS) 공격을 받을 위험성에 놓이게 됩니다.