혹시 여러분의 배포 계획이 코드의 불안정성 때문이 아니라, 컨테이너 기본 이미지 속에서 앱은 전혀 건드리지도 않는, 이름 모를 패키지가 떡하니 CVE 깃발을 흔들고 있다는 이유로 보안팀에게 제동이 걸린 경험, 있으신가요? 마치 블랙타이 갈라에 너무 캐주얼한 하와이안 셔츠를 입고 나타난 격이죠. 옷은 입었지만, 절대 초대받지 못할 겁니다.
이건 단순한 상상이 아닙니다. 작년 11월, 챗GPT 옵저버빌리티 플랫폼으로 주목받는 Langfuse를 자체 구축하던 팀이 Kubernetes 환경에서 프로덕션용 ClickHouse 데이터베이스를 준비하다가 똑같은 벽에 부딪혔습니다. ClickHouse 이미지를 AWS ECR에 올렸는데, 쾅! ClickHouse 자체의 문제가 아니라 기본 이미지에 숨어있던 치명적인 취약점 세 개가 발견된 거죠. 꼼꼼한 보안팀은 스캐너 보고서를 보고는 딱 잘라 ‘안 된다’고 했습니다.
이 글은 Docker Hardened Images(DHI)가 우리를 이 지긋지긋한 배포의 늪에서 어떻게 구해낼지에 대한 이야기입니다. DHI의 접근 방식을 우리가 가장 흔하게 접하는 ClickHouse 데이터베이스 이미지를 예로 들어 자세히 파헤쳐 보겠습니다.
ClickHouse: 외면할 수 없는 분석 파워하우스
먼저 ClickHouse 자체에 대해 간단히 짚고 넘어가죠. 대규모 분석 작업을 제대로 한다면 ClickHouse를 모를 리 없습니다. 이 오픈소스 컬럼형 데이터베이스는 정말 괴물 같은 성능을 자랑하며, 수십억 개의 행을 순식간에 처리하고 밀리초 단위로 결과를 뱉어냅니다. 전통적인 행 지향 데이터베이스는 잊으세요. ClickHouse는 속도를 위해 태어났습니다. Cloudflare, Uber, Spotify 같은 기업들이 이미 프로덕션에서 사용 중이며, Docker Hub에서 1억 회 이상 다운로드된 이 데이터베이스는 막대한 분석 처리량이 필요한 모든 이들의 사실상 표준 인프라 선택지가 되었습니다. 문제는, 언제나 기본 보안 태세였습니다. 개발자의 편의성에 맞춰져 있을 뿐, 엔터프라이즈 프로덕션 환경이 요구하는 철통같은 보안 강화에는 부족함이 많았죠. 그리고 이것이 바로 우리가 현재 겪는 곤경의 시작점입니다.
보이지 않는 과적재: 기본 이미지가 진짜 범인인 이유
표준 clickhouse/clickhouse-server 이미지는 (좋은 의도겠지만) 풀 Ubuntu 22.04 기반으로 만들어졌습니다. Ubuntu는 훌륭한 OS지만, ClickHouse처럼 고도로 전문화된 데이터베이스에게는 피크닉에 완전히 갖춰진 주방을 통째로 들고 가는 격입니다. ClickHouse가 전혀 필요로 하지 않는 Perl, 전체 패키지 관리자(apt), 수많은 시스템 유틸리티, 그리고 연쇄적인 종속성들을 잔뜩 싣고 옵니다. 이 패키지들 중 상당수는 상위 관리자로부터 보안 백포트가 오랫동안 이루어지지 않았습니다.
ClickHouse는 그 뛰어난 집중력으로 이들 중 대부분을 거의 건드리지 않습니다. 하지만 해당 패키지의 CVE는 분명히 실존합니다. Trivy나 Grype 같은 스캐너는 충실하게 이들을 꼬집어냅니다. AWS ECR은 편견 없는 논리적인 방식으로, 단순히 존재만 하는 취약한 라이브러리와 실제로 악용되는 라이브러리를 구분하지 못합니다. 여러분의 보안팀은 빨간불을 보고, 당연히도 배포를 차단합니다. 그들은 스캐너가 제공하는 정보를 바탕으로 자신의 역할을 하고 있는 겁니다.
물론, 영웅적인 방어를 펼치고 싶은 충동이 들 수 있습니다. 복잡한 위험 면제 문서를 작성하고, 여러분의 특정 워크로드가 왜 그 오래된 wget 라이브러리의 패치되지 않은 CVE-2021-31879를 절대 건드리지 않을 것인지에 대한 에세이를 써 내려가는 거죠. 이는 지치고 시간 낭비적인 과정입니다. 이 모든 카프카식 악몽을 완전히 피해 가는 유일한 해결책은, 단순히 불필요한 패키지를 제거하는 것입니다. 그리고 그것이야말로, 여러분, Docker Hardened Images(DHI)가 달성하고자 하는 목표입니다.
DHI: 핵심적인 하드웨어 필수품만 남기다
그렇다면 DHI는 과연 무엇을 해서 자기 공을 세우는 걸까요? 그것은 매우 단순하지만 지극히 영향력 있는 질문에서 시작합니다. 이 데이터베이스가 실제로 실행되기 위해 무엇이 필요한가? 방대하고 기능이 풍부한 Ubuntu 기반에서 시작해 CVE 수를 관리 가능한 수준으로 유지하려는 시도 대신, DHI는 ClickHouse에 필수적인 것만 엄선하여 제공합니다. 나머지 모든 것은? 다 제거합니다.
이 최소주의 접근 방식의 가장 즉각적이고, 솔직히 말해 기발한 결과는 무엇일까요? 런타임에 apt가 사라진다는 것입니다. 공격자가 컨테이너를 침해했다고 상상해 보세요. 내장된 패키지 관리자가 없으면, 악성 도구를 설치하거나 지속적인 거점을 마련할 수 있는 옵션이 훨씬 제한됩니다. curl이나 wget 같은 네트워크 유틸리티? 동일한 보안 의식 때문에 제거되었습니다.
DHI는 단순히 명백한 공격 벡터를 제거하는 데 그치지 않습니다. 더 깊이 들어가, 기본 OS나 다른 도구에서 사용될 수는 있지만 ClickHouse의 핵심 기능과는 전혀 관련 없는 라이브러리를 식별하고 제거합니다. 이것은 단순히 이미지 크기를 줄이는 것(물론 그것도 좋은 장점입니다)이 아닙니다. 이것은 공격 표면을 극적으로 줄여, 여러분의 배포를 본질적으로 더 탄력적으로 만들고, 가장 중요하게는 엄격한 엔터프라이즈 보안 환경 내에서 배포 가능하게 만드는 것입니다.
이렇게 생각해보세요. 표준 이미지는 모든 것이 완비된 집입니다. 필요할 수도 있는 모든 것을 갖추고 있고, 사실 필요 없는 것도 많죠. DHI 이미지는요? 편안하게 살기 위한 필수 구성 요소만으로 지어진, 세심하게 설계된 미니멀리스트 안식처입니다. 보안팀의 눈에는 그 안식처가 훨씬 더 매력적으로 보일 겁니다.
표준
clickhouse/clickhouse-server이미지는 풀 Ubuntu 22.04 기반으로 만들어졌습니다. 이 기본 이미지는 ClickHouse가 필요로 하지 않는 Perl, 시스템 유틸리티, apt 자체, 그리고 Ubuntu가 오래된 패키지를 가져왔기 때문에 단순히 이미지에 존재하는 수십 개의 연쇄 종속성 등 많은 것을 포함하고 있습니다. 많은 경우 Ubuntu 유지보수자는 상위에서 수정 사항을 백포트하지 않습니다.
필수성에 대한 이러한 끊임없는 초점은 DHI 이미지가 기존 이미지의 극히 일부에 불과하다는 것을 의미합니다. 더 작은 이미지는 더 빠른 다운로드, 더 빠른 배포, 그리고 잠재적인 취약점에 대한 발자국 감소를 의미합니다. 이것은 보안의 걸작이기도 한 효율성 게임입니다.
이것이 갖는 의미는 엄청납니다. 개발자에게는 보안 예외 처리에 쏟는 시간을 줄이고 기능 개발에 더 많은 시간을 할애할 수 있다는 뜻입니다. 보안팀에게는 더 깔끔한 보고서와 배포된 애플리케이션에 대한 더 높은 신뢰도를 의미합니다. 이것은 마침내 조화를 찾은 공생 관계이며, 모두 이미지 구축에 대한 보다 지능적인 접근 방식 덕분입니다.
왜 이것이 중요한가: 플랫폼 전환의 시작
이것은 단순히 강화된 ClickHouse 이미지에 대한 이야기가 아닙니다. 이것은 우리가 소프트웨어 배포에 대해 생각하는 방식에 대한 근본적인 플랫폼 전환을 밝히는 신호, 등대입니다. 수년간 우리는 기본 OS 계층이 불가피한 악이며, 대체로 그대로 받아들이는 기초 구성 요소라는 가정하에 운영해 왔습니다. 이러한 기초 계층의 CVEs의 확산은 DevOps 세계에서 지속적인 저강도 불안감의 윙윙거림이 되었습니다.
DHI와 그것이 대표하는 철학은 그 가정을 정면으로 도전하고 있습니다. 기본 이미지는 용인해야 할 정적 실체가 아니라, 그것이 호스팅하는 특정 애플리케이션에 맞게 공격적으로 최적화될 수 있고 되어야 하는 가변적인 구성 요소라고 주장합니다. 이것은 인프라에 적용된 AI 사고방식입니다. 핵심 요구 사항을 식별하고 나머지 모든 것을 무자비하게 최적화합니다.
우리는 기본 이미지의 보안 부채를 받아들이는 모델에서 보안 부채를 제거하는 모델로 이동하고 있습니다. 이것은 단순한 점진적인 개선이 아니라, 모놀리식 애플리케이션에서 마이크로서비스로의 전환, 또는 온프레미스 서버에서 클라우드 네이티브 아키텍처로의 전환과 같은 도약입니다. 이것은 우리 애플리케이션이 구축되고 배포되는 기반의 근본적인 변화입니다.
미래는 날렵하고 강력하다
AI가 기술 스택의 모든 계층에 계속 침투함에 따라, 우리는 이러한 종류의 지능적인 최적화를 더 많이 보게 될 것입니다. AI 기반 빌드 시스템이 특정 애플리케이션 이미지에서 불필요한 구성 요소를 동적으로 제거하여, 특정 런타임 요구 사항과 보안 정책에 맞춰주는 것을 상상해 보세요. ClickHouse를 위한 DHI는 오늘날 펼쳐지고 있는 이 미래에 대한 강력하고 실질적인 예입니다. 이것은 보안이 사후 대책이 아니라 인프라 자체의 내재적 속성인 미래입니다. 여러분의 배포가 차단되지 않고, 안전하고 세상이 던지는 어떤 것이든 처리할 준비가 된 상태로 순조롭게 진행되는 미래입니다. 그리고 모든 개발자나 Ops 엔지니어에게 있어, 이것은 기대해 볼 만한 미래입니다.
**
🧬 관련 인사이트
- 더 읽어보기: HCP Packer의 SBOM 스캐닝: 몇 초 만에 취약점 발견
- 더 읽어보기: 자체 구축 클라우드 방화벽, 실시간 DDoS 공격 차단
자주 묻는 질문**
Docker Hardened Image(DHI)란 정확히 무엇인가요? DHI는 애플리케이션 실행에 필요한 최소한의 구성 요소만으로 구축된 컨테이너 이미지로, 공격 표면과 잠재적인 취약점을 극적으로 줄입니다.
DHI 이미지는 시작 속도가 느린가요? 일반적으로 그렇지 않습니다. 불필요한 오버헤드를 제거하고 이미지 크기를 줄임으로써, DHI 이미지는 종종 과도하게 부풀려진 기존 이미지보다 더 빠르게 다운로드되고 시작될 수 있습니다.
이것은 ClickHouse만을 위한 것인가요? DHI는 다양한 애플리케이션에 적용할 수 있는 방법론이지만, 이 글은 특히 ClickHouse에 대한 적용에 초점을 맞추고 있습니다.
