linux-kernel

넷플릭스의 마운트 메 (새 탭에서 열림)

넷플릭스는 컨테이너 런타임을 현대화하는 과정에서 수백 개의 컨테이너가 동시에 부팅될 때 시스템이 멈추거나 헬스 체크가 실패하는 심각한 병목 현상에 직면했습니다. 조사 결과, 이는 컨테이너 보안을 위해 도입된 사용자 네임스페이스(User Namespace)의 `idmap` 마운트 작업이 리눅스 커널의 VFS(가상 파일 시스템) 전역 잠금 장치에서 경합을 일으키기 때문으로 밝혀졌습니다. 특히 이러한 현상은 구형 다중 소켓(NUMA) 하드웨어 아키텍처에서 더욱 두드러지게 나타났으며, 최신 단일 소켓 인스턴스로 전환함으로써 스케일링 성능을 크게 개선할 수 있었습니다. **컨테이너 보안 강화와 마운트 폭증의 관계** - 넷플릭스는 보안 강화를 위해 각 컨테이너에 고유한 사용자 범위를 할당하는 새로운 런타임(Kubelet + Containerd)으로 전환했습니다. - 파일 소유권을 실제로 변경하는 비용을 줄이기 위해 커널의 `idmap` 마운트 기능을 사용하는데, 이는 각 레이어마다 `open_tree`, `mount_setattr`, `move_mount` 등의 호출을 발생시킵니다. - 50개의 레이어를 가진 컨테이너 100개를 동시에 실행할 경우, 이론적으로 약 20,000번 이상의 마운트 관련 작업이 수행되며 이는 커널의 마운트 테이블 전역 락(Global Lock)에 엄청난 부하를 줍니다. **커널 및 하드웨어 수준의 병목 현상 진단** - 시스템 분석 결과, CPU는 커널의 `path_init()` 함수 내 시퀀스 락(Sequence Lock)을 기다리는 스핀 루프(Spin Loop)에서 대부분의 시간을 소비하며 'Pause' 명령어를 반복 실행했습니다. - TMA(Topdown Microarchitecture Analysis) 분석에 따르면 파이프라인 슬롯의 95.5%가 경합된 액세스로 인해 중단되었으며, 57%는 가짜 공유(False Sharing)로 인해 발생했습니다. - 여러 코어가 동일한 캐시 라인에 접근하려고 시도하면서 캐시 라인 바운싱(Cache Line Bouncing) 현상이 발생하여 시스템 성능이 급격히 저하되었습니다. **인스턴스 아키텍처에 따른 성능 차이** - 테스트 결과, 5세대 인텔 듀얼 소켓 인스턴스인 `r5.metal`은 100개 이상의 컨테이너가 동시에 실행될 때 성능이 급격히 저하되며 실패하는 모습을 보였습니다. - 반면, 단일 소켓 및 단일 NUMA 도메인을 사용하는 7세대 인스턴스(`m7i.metal-24xl`, `m7a.24xlarge`)는 높은 동시성 환경에서도 훨씬 낮은 지연 시간과 높은 성공률을 유지했습니다. - 이는 NUMA 아키텍처의 프로세서 간 상호 연결(Interconnect) 대기 시간이 전역 락 경합 상황에서 병목 현상을 수배로 증폭시키기 때문입니다. 대규모 컨테이너 환경을 운영한다면 컨테이너 이미지의 레이어 수를 최소화하여 마운트 발생 횟수를 줄여야 합니다. 또한, 컨테이너 생성 및 삭제가 빈번한 워크로드의 경우 다중 소켓 기반의 구형 인스턴스보다는 메모리 접근 대기 시간이 짧고 락 경합에 유리한 최신 단일 소켓 혹은 단일 NUMA 노드 아키텍처를 선택하는 것이 성능 안정성에 유리합니다.

런타임 보안을 위한 eBPF 강화: Datadog Workload Protection의 교훈 (새 탭에서 열림)

Datadog은 지난 5년간 수천 개의 환경에서 eBPF 기반의 런타임 보안 제품인 'Workload Protection'을 운영하며 얻은 실전 경험과 교훈을 공유합니다. eBPF는 기존 커널 모듈이나 감사(Audit) 프레임워크보다 안전하고 효율적이지만, 대규모 운영 환경에서는 커널 호환성이나 성능 오버헤드 같은 복잡한 문제들이 발생합니다. 결론적으로 eBPF는 강력한 도구이나, 실제 운영 환경에서 신뢰성을 확보하기 위해서는 단순한 구현을 넘어 정교한 모니터링과 배포 전략이 필수적입니다. **기존 커널 모니터링 기술의 한계와 평가** * **커널 모듈(LKM):** 시스템의 거의 모든 부분을 제어할 수 있는 강력한 권한을 가지지만, 코드 오류가 커널 전체의 크래시로 이어질 수 있어 안정성 측면에서 위험부담이 큽니다. * **전통적인 트레이싱 인터페이스:** inotify, fanotify, kprobes 등은 시스템 내부를 들여다볼 수 있게 해주지만, 전체적인 시스템 활동을 파악하려면 여러 도구를 복잡하게 조합해야 하는 파편화 문제가 있습니다. * **ptrace 및 seccomp-bpf:** 사용자 공간의 프로세스를 추적하는 데 유용하지만, 모든 프로세스 액세스를 감시하기에는 성능 오버헤드가 발생하며 커널 수준의 가시성이 부족합니다. * **Linux Audit 프레임워크:** 가장 널리 사용되는 보안 솔루션이지만, 대량의 이벤트가 발생할 때 시스템 성능에 상당한 영향을 미치는 단점이 있습니다. **보안 제품에 eBPF를 선택한 핵심 이유** * **검증된 안전성:** eBPF 프로그램은 로드되기 전 커널 검증기(Verifier)를 통해 무한 루프나 잘못된 메모리 접근 여부를 정적으로 분석하므로 커널 모듈보다 훨씬 안전합니다. * **통합 가시성:** 프로세스 실행, 파일 시스템 접근, 네트워크 활동 등을 단일 메커니즘으로 모두 추적할 수 있어 시스템 전반에 대한 통합적인 가시성을 제공합니다. * **컨테이너 최적화:** 네임스페이스(Namespace)와 cgroup에 대한 이해도가 높아 컨테이너 환경에서 일관된 모니터링이 가능하며, 특히 CO-RE(Compile Once – Run Everywhere) 도입으로 배포가 쉬워졌습니다. * **강력한 제어 권한:** BPF LSM 기능을 통해 단순한 모니터링을 넘어 시스템 호출을 차단하는 등의 강제 접근 제어(Mandatory Access Control)를 수행할 수 있습니다. **대규모 생산 환경에서의 운영 교훈** * **커널 호환성 유지:** 특정 커널 버전에서는 작동하지만 다른 버전에서는 실패하는 경우를 방지하기 위해 프로그램 로드 및 부착(Attach) 과정을 정교하게 관리해야 합니다. * **성능 비용 관리:** eBPF가 효율적이긴 하지만, 수많은 훅(Hook)이 동시에 실행될 때 발생하는 성능 비용을 지속적으로 측정하고 제어하는 메커니즘이 필요합니다. * **풍부한 데이터 처리:** 캡처된 원시 데이터를 단순히 전달하는 것이 아니라, 보안 분석에 유용하도록 문맥(Context)을 보강하고 정확하게 강화하는 로직이 중요합니다. * **안전한 변경 배포:** 수천 대의 호스트에 영향을 줄 수 있으므로, eBPF 프로그램의 변경 사항을 안전하게 롤아웃하고 문제 발생 시 즉시 감지할 수 있는 시스템을 갖춰야 합니다. **실용적인 제언** eBPF를 도입할 때 "안전하고 성능 저하가 없다"는 마케팅적 수사에만 의존해서는 안 됩니다. 모니터링하려는 워크로드의 특성에 따라 성능 임팩트가 달라질 수 있으므로, 자체적인 성능 모니터링 지표를 구축하고 커널 버전별로 철저한 회귀 테스트를 거치는 것을 추천합니다.

Not just another network latency issue: How we unraveled a series of hidden bottlenecks (새 탭에서 열림)

사용량 추정 서비스의 배포 시마다 반복되는 높은 시작 지연 시간(Startup Latency) 문제를 해결하기 위해, 시스템 전반의 네트워크 경로와 인프라 계층을 다각도로 조사했습니다. 단순히 애플리케이션 코드를 수정하는 수준을 넘어, 사이드카 프록시 설정, 리눅스 커널 버그, 클라우드 인스턴스의 네트워크 대역폭 한계 등 복합적인 병목 현상을 단계별로 추적해 해결했습니다. 최종적으로 인프라 최적화와 우아한 종료(Graceful Shutdown) 메커니즘을 결합하여 서비스 안정성을 확보하고 팀의 경보 피로도를 대폭 낮추는 결론에 도달했습니다. **Envoy 사이드카의 CPU 병목 해소** * 배포 단계에서 원격 캐시 데이터를 대량으로 불러올 때, 사이드카 프록시인 Envoy가 모든 쿼리를 배치 처리하며 과도한 CPU를 사용함을 확인했습니다. * Envoy가 할당된 CPU 자원(2코어)을 모두 소진하여 쓰로틀링(Throttling)이 발생했고, 이로 인해 패킷 처리 지연과 TCP 재전송(Retransmit)이 급증했습니다. * Envoy에 할당되는 CPU 자원을 늘려 1차적인 지연 시간 수치를 개선했으나, 여전히 배포 중 지연 시간이 300ms에서 1s 사이를 진동하는 문제가 남았습니다. **리눅스 커널 버그 패치 및 트래픽 분산** * 조사 과정에서 AWS의 Elastic Network Adapter(ENA)를 사용할 때 발생하는 리눅스 커널 버그를 발견했습니다. * 해당 버그는 네트워크 트래픽을 8개의 전송 큐(Transmit Queue)에 분산하지 않고 첫 번째 큐에만 몰아넣어 병목을 유발하고 있었습니다. * 트래픽을 모든 큐에 골고루 분산시키는 핫픽스를 적용하여, 배포 기간 외에 간헐적으로 발생하던 지연 시간 스파이크 문제를 해결했습니다. **AWS 인스턴스 네트워크 대역폭 최적화** * 커널 수정 후에도 배포 중 지연이 지속되자 AWS 전용 메트릭인 `bw_in_allowance_exceeded`와 `bw_out_allowance_exceeded`를 분석했습니다. * 분석 결과, 배포 시 발생하는 급격한 트래픽이 인스턴스 유형별로 할당된 최대 네트워크 대역폭을 초과하여 하이퍼바이저 수준에서 패킷 드롭이 발생하고 있었습니다. * 이를 해결하기 위해 더 높은 대역폭을 제공하는 네트워크 최적화(Network-optimized) EC2 인스턴스로 마이그레이션하여 대역폭 제한 문제를 해결했습니다. **종료되는 파드로의 요청 라우팅 방지** * 모든 인프라 개선 후에도 남아있던 1초 가량의 지연 스파이크가 원격 캐시 파드의 종료(Terminating) 시점과 일치함을 포착했습니다. * 기존의 우아한 종료 로직이 Envoy 클라이언트의 처리 중인 요청(In-flight requests)을 충분히 기다리지 못해, 종료 중인 파드에 요청이 전달되어 타임아웃과 재시도가 발생하고 있었습니다. * 파드에 `preStop` 훅을 구현하여 종료 전 유지 관리 모드 상태임을 클라이언트에 알리고, 모든 요청이 완료될 때까지 대기하도록 설정하여 지연 시간을 최종적으로 안정화했습니다. 성능 최적화 과정에서 단일 원인을 찾기보다 네트워크 스택의 각 계층(프록시, OS 커널, 클라우드 인프라, 애플리케이션 생명주기)을 체계적으로 검증하는 접근 방식이 중요합니다. 특히 대규모 트래픽이 발생하는 배포 시점에는 시스템의 숨겨진 한계치가 드러나기 쉬우므로, 클라우드 제공업체의 전용 메트릭과 네트워크 큐 상태를 면밀히 모니터링할 것을 권장합니다.

Escaping containers using the Dirty Pipe vulnerability | Datadog Security Labs (새 탭에서 열림)

리눅스 커널의 Dirty Pipe(CVE-2022-0847) 취약점은 권한이 없는 프로세스가 읽기 전용 파일에 데이터를 쓸 수 있게 하여, 컨테이너 환경에서 호스트의 권한을 탈취하는 '컨테이너 탈출'을 가능하게 한다. 이 글은 Kubernetes 환경에서 runC 바이너리를 덮어쓰는 방식을 통해, 공격자가 격리된 컨테이너를 벗어나 호스트 수준의 관리자 권한을 획득하는 과정을 상세히 설명한다. 이는 과거 runC 취약점 패치가 성능 최적화를 위해 커널 페이지 캐시를 공유한다는 점을 역이용한 결과로, 현대적 컨테이너 런타임 구조 내의 보안 허점을 시사한다. ### 컨테이너 런타임과 OCI 명세의 이해 * Kubernetes는 컨테이너 실행을 위해 containerd나 CRI-O 같은 고수준 런타임을 사용하며, 이들은 내부적으로 runC와 같은 저수준 OCI(Open Container Interface) 런타임을 호출한다. * runC는 리눅스의 네임스페이스와 제어 그룹(cgroups)을 설정하여 프로세스를 논리적으로 격리하며, 최종적으로 `execve` 시스템 콜을 통해 사용자가 지정한 엔트리포인트를 실행한다. * 컨테이너 프로세스가 생성되는 시점에 `/proc/self/exe` 파일 기술자(File Descriptor)를 통해 호스트의 runC 바이너리에 접근할 수 있는 경로가 일시적으로 열리게 된다. ### runC 취약점의 역사적 맥락 * 과거 CVE-2019-5736 취약점은 컨테이너 내부에서 호스트의 runC 바이너리를 직접 수정하여 루트 권한을 획득하는 방식을 사용했다. * 이를 방어하기 위해 runC 개발팀은 바이너리를 복제(clone)하여 실행하거나, 호스트의 runC 바이너리를 읽기 전용으로 마운트하여 컨테이너 내부에 제공하는 패치를 적용했다. * 하지만 Dirty Pipe 취약점은 커널 페이지 캐시를 조작하여 읽기 전용 파일조차 수정할 수 있게 하므로, 성능 향상을 위해 도입된 '읽기 전용 공유 방식'이 오히려 새로운 공격 경로가 되었다. ### Dirty Pipe를 이용한 컨테이너 탈출 메커니즘 * 공격자는 권한이 없는 컨테이너 내부에서 스크립트를 실행하여 호스트의 runC가 다시 실행되기를 기다린다(예: 관리자의 `kubectl exec` 호출). * runC가 실행되는 순간, 공격 프로세스는 `/proc/<runC-pid>/exe` 경로를 통해 Dirty Pipe 취약점을 가동한다. * 이 취약점은 커널 페이지 캐시 수준에서 메모리를 덮어쓰기 때문에, 호스트의 물리적 디스크에 저장된 runC 파일은 건드리지 않으면서도 현재 실행 중인 runC 프로세스를 악성 바이너리로 교체할 수 있다. ### 공격 증명(PoC) 및 실행 과정 * 공격 스크립트는 루프를 돌며 `ps` 명령어로 `/proc/self/exe`를 참조하는 runC 프로세스의 PID를 지속적으로 감시한다. * 대상 PID가 발견되면 Dirty Pipe 익스플로잇 코드를 실행하여, 해당 프로세스가 참조하는 바이너리 데이터를 호스트 권한으로 실행될 악성 ELF 파일로 덮어쓴다. * 조작된 runC는 호스트 시스템에서 루트 권한으로 실행되며, 공격자가 의도한 명령(예: 호스트의 `/tmp/hacked` 파일 생성 등)을 수행한 뒤 호스트 전체를 장악할 수 있게 한다. ### 보안 결론 및 대응 방안 * 본 취약점은 컨테이너 격리 기술 자체가 아닌 리눅스 커널의 메모리 관리 결함에서 비롯된 것이므로, 가장 확실한 해결책은 Dirty Pipe 보안 패치가 적용된 최신 커널 버전으로 노드를 업데이트하는 것이다. * 컨테이너 환경에서는 `/proc` 파일 시스템에 대한 비정상적인 접근을 모니터링하고, 불필요한 고권한(Privileged) 컨테이너 사용을 지양하는 보안 정책이 병행되어야 한다. * 시스템 재부팅이나 캐시 초기화 시 조작된 페이지 캐시가 사라져 공격 흔적이 휘발될 수 있으므로, 실시간 침입 탐지 시스템을 통한 조기 대응이 중요하다.