2.2. 호스트 및 VM 보안 이해
컨테이너와 가상 머신 모두 호스트에서 실행 중인 애플리케이션을 운영 체제 자체에서 분리하는 방법을 제공합니다. OpenShift Container Platform에서 사용하는 운영 체제인 RHCOS를 이해하면 호스트 시스템이 컨테이너와 호스트를 서로 보호하는 방법을 알 수 있습니다.
2.2.1. RHCOS(Red Hat Enterprise Linux CoreOS)의 컨테이너 보안
컨테이너를 사용하면 동일한 커널 및 컨테이너 런타임을 통해 각 컨테이너를 가동하여 동일한 호스트에서 실행되도록 많은 애플리케이션을 배포하는 작업이 단순화됩니다. 애플리케이션은 많은 사용자가 소유할 수 있으며, 개별적으로 유지되기 때문에 서로 다르거나 호환되지 않는 버전의 애플리케이션도 문제없이 동시에 실행될 수 있습니다.
Linux에서 컨테이너는 특별한 유형의 프로세스이므로 컨테이너 보안은 여러 가지 면에서 기타 실행 중인 프로세스를 보호하는 것과 비슷합니다. 컨테이너를 실행하는 환경은 컨테이너를 서로 보호할 뿐만 아니라 호스트에서 실행 중인 다른 프로세스 및 컨테이너로부터 호스트 커널을 보호할 수 있는 운영 체제로 시작합니다.
OpenShift Container Platform 4.14는 RHEL(Red Hat Enterprise Linux)을 작업자 노드로 사용하는 옵션과 함께 RHCOS 호스트에서 실행되므로 다음 개념이 배포된 모든 OpenShift Container Platform 클러스터에 기본적으로 적용됩니다. 이러한 RHEL 보안 기능은 OpenShift Container Platform에서 컨테이너를 더 안전하게 실행할 수 있게 하는 핵심 요소입니다.
- Linux 네임스페이스를 사용하면 특정 글로벌 시스템 리소스를 추상화하여 네임스페이스에서 처리할 별도의 인스턴스로 표시할 수 있습니다. 따라서 여러 컨테이너가 충돌없이 동일한 컴퓨팅 리소스를 동시에 사용할 수 있습니다. 기본적으로 호스트와 분리된 컨테이너 네임스페이스에는 마운트 테이블, 프로세스 테이블, 네트워크 인터페이스, 사용자, 제어 그룹, UTS 및 IPC 네임스페이스가 있습니다. 호스트 네임스페이스에 직접 액세스해야 하는 컨테이너에는 높은 권한이 있어야 해당 액세스를 요청할 수 있습니다. 네임스페이스 유형에 대한 자세한 내용은 RHEL 8 컨테이너 설명서에서 Red Hat Systems의 컨테이너 개요를 참조하십시오.
- SELinux에서는 컨테이너 간에 서로 격리하고 컨테이너를 호스트에서 격리된 상태로 유지하는 추가 보안 계층을 제공합니다. 관리자는 SELinux를 사용하여 모든 사용자, 애플리케이션, 프로세스 및 파일에 MAC(필수 액세스 제어)를 적용할 수 있습니다.
RHCOS에서 SELinux를 비활성화하는 것은 지원되지 않습니다.
- CGroup(제어 그룹)은 프로세스 컬렉션의 리소스 사용량(CPU, 메모리, 디스크 I/O, 네트워크 등)을 제한, 설명 및 격리합니다. CGroup을 사용하면 동일한 호스트의 컨테이너가 서로 영향을 주지 않습니다.
- 보안 컴퓨팅 모드(seccomp) 프로파일은 사용 가능한 시스템 호출을 제한하기 위해 컨테이너와 연관될 수 있습니다. seccomp에 관한 자세한 내용은 OpenShift 보안 안내서의 94페이지를 참조하십시오.
- RHCOS를 사용하여 컨테이너를 배포하면 호스트 환경을 최소화하고 컨테이너에 맞게 조정하여 공격 면적을 줄입니다. CRI-O 컨테이너 엔진은 데스크톱 지향 독립 실행형 기능을 구현하는 다른 컨테이너 엔진과 달리 컨테이너를 실행하고 관리하기 위해 쿠버네티스 및 OpenShift Container Platform에 필요한 기능만 구현하여 공격 면적을 더 줄입니다.
RHCOS는 OpenShift Container Platform 클러스터에서 컨트롤 플레인(마스터) 및 작업자 노드로 작동하도록 특별히 구성된 RHEL(Red Hat Enterprise Linux) 버전입니다. 따라서 RHCOS는 쿠버네티스 및 OpenShift Container Platform 서비스와 함께 컨테이너 워크로드를 효율적으로 실행하도록 조정됩니다.
OpenShift Container Platform 클러스터에서 RHCOS 시스템을 추가로 보호하려면 호스트 시스템 자체를 관리하거나 모니터링하는 컨테이너를 제외한 대부분의 컨테이너는 루트가 아닌 사용자로 실행해야 합니다. 고유한 OpenShift Container Platform 클러스터를 보호하는 데 권장되는 모범 사례는 권한 수준을 낮추거나 가능한 최소 권한으로 컨테이너를 생성하는 것입니다.
2.2.2. 가상화 및 컨테이너 비교
기존 가상화에서는 동일한 물리적 호스트에서 애플리케이션 환경을 분리한 상태로 유지할 수 있는 또 다른 방법을 제공합니다. 그러나 가상 머신은 컨테이너와 다른 방식으로 작동합니다. 가상화는 게스트 가상 머신(VM)을 가동시키는 하이퍼바이저를 사용하며, 각 가상 머신에는 실행 중인 커널로 표시되는 자체 운영 체제(OS)와 실행 중인 애플리케이션 및 해당 종속 항목이 있습니다.
VM을 사용하면 하이퍼바이저에서 게스트 간에 서로 분리하고 호스트 커널에서 게스트를 분리합니다. 하이퍼바이저에 액세스하는 개인과 프로세스 수가 적어지므로 물리 서버의 공격 면적을 줄입니다. 보안은 여전히 모니터링해야 하지만, 하나의 게스트 VM은 하이퍼바이저 버그를 사용하여 다른 VM 또는 호스트 커널에 액세스할 수 있습니다. 또한 OS에 패치가 필요한 경우 해당 OS를 사용하는 모든 게스트 VM에서 패치를 적용해야 합니다.
컨테이너는 게스트 VM 내부에서 실행될 수 있으며 이와 같은 조치 바람직한 경우가 있을 수 있습니다. 예를 들어, 애플리케이션을 클라우드로 수정 없이 그대로 리프트 앤 시프트(lift-and-shift) 방식으로 배포하고 이동하기 위해 컨테이너에 기존 애플리케이션을 배포할 수 있습니다.
그러나 단일 호스트에서 컨테이너를 분리하면 더 가볍고 유연하며 쉽게 확장되는 배포 솔루션이 제공됩니다. 이 배포 모델은 특히 클라우드 네이티브 애플리케이션에 적합합니다. 컨테이너는 일반적으로 VM보다 훨씬 작으며 메모리와 CPU 사용량이 적습니다.
컨테이너와 VM의 차이점에 관해 알아보려면 RHEL 7 컨테이너 설명서의 Linux 컨테이너와 KVM 가상화 비교를 참조하십시오.
2.2.3. OpenShift Container Platform 보호
OpenShift Container Platform을 배포할 때 설치 프로그램 프로비저닝 인프라(사용 가능한 플랫폼이 여러 개) 또는 사용자가 프로비저닝한 자체 인프라 중에서 선택할 수 있습니다. FIPS 모드 활성화 또는 처음 부팅 시 필요한 커널 모듈 추가와 같은 일부 낮은 수준의 보안 관련 구성은 사용자 프로비저닝 인프라를 활용할 수 있습니다. 마찬가지로 사용자 프로비저닝 인프라는 연결 해제된 OpenShift Container Platform 배포에 적합합니다.
OpenShift Container Platform의 보안 향상 및 기타 구성 변경과 관련된 목표는 다음과 같습니다.
- 기본 노드를 최대한 일반적으로 유지합니다. 비슷한 노드를 신속하고 규범에 맞는 방식으로 쉽게 제거하고 구동할 수 있어야 합니다.
- 노드를 일회성으로 직접 변경하지 말고 최대한 OpenShift Container Platform에서 노드 수정을 관리합니다.
이러한 목표를 달성하기 위해 대부분의 노드 변경은 설치 중 Ignition을 사용하거나 나중에 Machine Config Operator가 노드 세트에 적용하는 MachineConfig를 사용하여 수행해야 합니다. 이러한 방식으로 수행할 수 있는 보안 관련 구성 변경의 예는 다음과 같습니다.
- 커널 인수 추가
- 커널 모듈 추가
- FIPS 암호화 지원 활성화
- 디스크 암호화 구성
- chrony 타임 서비스 구성
Machine Config Operator 외에도 CVO(Cluster Version Operator)에서 관리하며 OpenShift Container Platform 인프라를 구성하는 데 사용할 수 있는 Operator는 여러 가지가 있습니다. CVO를 사용하면 OpenShift Container Platform 클러스터 업데이트의 여러 요소를 자동화할 수 있습니다.
추가 리소스
