Docker에서 진정한 멀티 테넌트 격리 달성하기

요약

Docker 컨테이너는 호스트 커널을 공유하므로, 테넌트가 서로 신뢰하지 않을 수 있는 멀티 테넌트 환경에서 보안 문제가 될 수 있습니다. 이 글은 기본 Docker 설정에서의 격리 격차를 설명하고 Linux 네임스페이스, cgroups, 사용자 네임스페이스, seccomp, AppArmor 및 하드웨어 가상화를 사용하여 격리를 강화하는 구체적인 단계를 제공합니다. 테넌트별 Docker 데몬을 구성하고, gVisor 또는 Firecracker와 같은 샌드박싱 도구를 사용하여 더 강력한 격리를 제공하며, Kubernetes를 사용한 멀티 테넌시 오케스트레이션을 배우게 됩니다. 또한 추가적인 분리 계층을 위해 KVM 기반 가상화를 제공하는 적절한 인프라 제공업체를 선택하는 방법도 다룹니다. 마지막으로, Docker로 안전한 멀티 테넌트 워크로드를 실행하기 위한 청사진을 갖게 됩니다.

단일 Docker 호스트에서 여러 테넌트를 호스팅할 때, Linux 네임스페이스와 cgroups에 기반한 기본 컨테이너 격리만으로는 충분하지 않은 경우가 많습니다. 한 테넌트에서 컨테이너 이스케이프가 발생하면 전체 호스트와 다른 모든 컨테이너가 손상될 수 있습니다. 이 문제는 공유 호스팅, SaaS 플랫폼 또는 신뢰할 수 없는 코드가 자체 코드와 함께 실행되는 모든 시나리오에서 특히 심각합니다. 좋은 소식은 여러 격리 기술을 쌓아 강화된 멀티 테넌트 환경을 구축할 수 있다는 것입니다. 이 가이드는 사용자 네임스페이스와 같은 쉬운 방법부터 샌드박스 런타임 및 인프라 선택과 같은 고급 조치까지 여섯 가지 실용적인 단계를 안내합니다.

Docker의 기본 격리 이해

Docker는 Linux 네임스페이스를 사용하여 프로세스, 네트워크, 파일 시스템 및 기타 리소스를 격리합니다. Cgroups는 CPU, 메모리 및 I/O를 제한합니다. 그러나 이들은 단일 커널을 공유하므로 커널의 취약점이 모든 컨테이너에 영향을 미칠 수 있습니다. 진정한 멀티 테넌시, 특히 신뢰할 수 없는 테넌트의 경우 심층 방어가 필요합니다. 멀티 테넌트 Docker 아키텍처 설계: 올바른 격리 수준 선택에서 논의된 바와 같이 격리 수준은 약한(네임스페이스 전용) 것부터 강한(하드웨어 가상화) 것까지 다양합니다. 가장 약한 것부터 구축해 보겠습니다.

1단계: 사용자 네임스페이스 활성화

기본적으로 컨테이너 내의 root는 호스트의 root에 매핑됩니다. 컨테이너 탈출 시 전체 호스트 액세스 권한이 부여됩니다. 사용자 네임스페이스는 컨테이너 root를 외부의 비-루트 사용자로 다시 매핑합니다. dockerd --userns-remap=default로 전역적으로 활성화하거나 --userns=host로 컨테이너별로 활성화합니다. 이 간단한 단계는 많은 권한 상승 공격을 제거합니다. 애플리케이션을 테스트하세요. 호스트 수준 권한이 필요한 일부(예: 파일 시스템 마운트)는 작동하지 않을 수 있습니다. Drupal 또는 WordPress 사이트의 경우 일반적으로 안전합니다.

2단계: Seccomp 및 AppArmor 프로필 적용

Seccomp는 컨테이너가 호출할 수 있는 시스템 호출을 제한합니다. Docker는 mount 및 reboot와 같은 위험한 시스템 호출을 차단하는 기본 seccomp 프로필과 함께 제공됩니다. 멀티 테넌트의 경우 더 강화하여 탈출 도구가 사용하는 일반적이지 않은 시스템 호출을 차단합니다. 마찬가지로 AppArmor는 컨테이너 프로세스를 제한할 수 있습니다. 커널 인터페이스에 대한 쓰기 액세스를 거부하고 파일 경로를 제한하는 사용자 지정 AppArmor 프로필을 만듭니다. 둘 다 --security-opt 플래그를 통해 설정됩니다. 계층적 방어를 위해 결합하세요.

3단계: 테넌트별 Docker 데몬 사용

모든 테넌트에 대해 단일 Docker 데몬을 실행하는 것은 위험합니다. 컨테이너 탈출 시 데몬 소켓에 액세스할 수 있습니다. Docker-in-Docker(DinD) 또는 원격 데몬 엔드포인트를 사용하여 테넌트별로 데몬을 격리합니다. 예를 들어 --privileged를 사용하여 컨테이너 내에서 Docker 데몬을 실행할 수 있지만 이는 격리를 약화시킵니다. 더 나은 방법: 별도의 VM에서 별도의 데몬을 실행하거나 사용자 네임스페이스와 함께 Docker의 실험적인 --group 기능을 사용합니다. 오케스트레이션의 경우 컨테이너 탈출 방어: 멀티 테넌트 호스팅을 위한 Docker 격리 실용 가이드에서 다루는 것처럼 Kubernetes 네임스페이스 기반 격리가 더 실용적입니다.

4단계: 샌드박스 런타임 고려

Linux 커널 자체를 신뢰할 수 없는 경우, 경량 VM 계층을 추가하는 샌드박스 런타임을 사용하세요. gVisor(runsc)는 시스템 호출을 가로채고 자체 커널을 구현하는 반면, Firecracker는 하드웨어 가상화와 함께 마이크로 VM을 사용합니다. 둘 다 containerd 런타임을 통해 Docker와 통합됩니다. 예를 들어 Docker 데몬 구성에 "runtimes": {"runsc": {}}를 추가하고 --runtime=runsc로 컨테이너를 실행합니다. 성능 오버헤드는 5~15%이지만 격리는 훨씬 더 강력합니다. 높은 보안이 필요한 멀티 테넌트 설정에 이상적입니다.

5단계: Kubernetes 및 보안 정책으로 오케스트레이션

Kubernetes는 네임스페이스, Pod 보안 표준 및 NetworkPolicy를 통해 기본 멀티 테넌시를 제공합니다. 리소스 할당량으로 테넌트별 네임스페이스를 정의하고 제한된 포드 보안 컨텍스트(모든 기능 드롭, 읽기 전용 루트 파일 시스템)를 적용합니다. OPA/Gatekeeper와 같은 승인 컨트롤러는 잘못된 구성을 차단할 수 있습니다. 많은 테넌트를 관리하는 경우 Kubernetes는 격리 적용을 자동화합니다. 프로덕션 규모 오케스트레이션에 대해서는 Docker Compose를 넘어: 프로덕션 준비 컨테이너화 애플리케이션 오케스트레이션을 참조하세요.

6단계: 올바른 호스팅 제공업체 선택

인프라 제공업체의 하이퍼바이저가 중요합니다. 공유 호스팅(OpenVZ)의 Docker는 약한 격리를 제공합니다. 한 테넌트가 다른 프로세스를 볼 수 있습니다. KVM 또는 VMware를 사용하는 제공업체를 선호하세요. 이들은 하드웨어 수준 분리를 제공합니다. DigitalOcean, Kamatera 또는 AWS와 같은 제공업체는 전용 리소스가 있는 KVM 기반 VPS를 제공합니다. 베어메탈의 경우 중첩 컨테이너를 위해 BIOS 수준 가상화가 활성화되어 있는지 확인하세요. 하이퍼바이저 계층에서 테넌트를 격리하는 제공업체는 컨테이너 격리를 보완합니다. 안전하고 효율적인 웹 호스팅을 위한 Docker 격리 마스터하기에 자세히 설명된 대로 호스트 OS도 최소 공격 표면으로 강화해야 합니다.

주의사항 및 절충점

추가 계층마다 복잡성과 성능 비용이 증가합니다. 사용자 네임스페이스는 호스트 마운트 볼륨을 손상시킬 수 있습니다. Seccomp 프로필은 애플리케이션별로 조정해야 합니다. gVisor와 같은 샌드박스 런타임은 모든 시스템 호출을 지원하지 않으므로 앱이 작동하지 않을 수 있습니다. 테넌트별 Docker 데몬은 메모리 오버헤드를 증가시킵니다. 위협 모델에 맞는 격리 수준을 선택하세요. 신뢰할 수 있는 테넌트의 경우 기본 네임스페이스로 충분할 수 있고, 공개 SaaS의 경우 런타임 샌드박스 및 Kubernetes 정책에 투자하세요. 프로덕션 전에 철저히 테스트하세요.

결론

Docker에서 진정한 멀티 테넌트 격리는 여러 커널 기능, 런타임 샌드박스 및 오케스트레이션 제어를 계층화하여 달성할 수 있습니다. 사용자 네임스페이스와 seccomp로 시작한 다음, 테넌트별 데몬 또는 샌드박스 런타임으로 발전하세요. 대규모의 경우 Kubernetes는 정책 기반 격리를 제공합니다. 항상 평판이 좋은 제공업체의 하이퍼바이저 수준 분리 호스트와 함께 사용하세요. 단일 기술로는 완벽할 수 없지만, 이를 결합하면 강력한 방어가 됩니다. 테넌트와 보안 감사 모두가 만족할 것입니다.