kubectl cp 한 줄이 컨테이너 탈출의 문이 되는 이유

흔히 쓰는 명령어가 보안 구멍이라니

쿠버네티스를 다뤄본 분이라면 kubectl cp 명령어를 한 번쯤은 써봤을 거예요. 컨테이너 안에 있는 파일을 호스트로 꺼내거나, 반대로 호스트의 파일을 컨테이너 안으로 밀어 넣을 때 쓰는 편리한 명령어죠. 그런데 보안 연구팀 Xint가 이 평범한 명령어를 이용해 컨테이너 안에서 호스트 시스템 권한을 탈취하는 시나리오를 공개했어요. 흔히 '컨테이너 탈출(container escape)'이라고 부르는 공격이고, CopyFail이라는 별명이 붙었어요.

먼저 컨테이너 탈출이 뭔지부터 짧게 짚을게요. 컨테이너는 호스트 OS 위에서 격리된 채로 돌아가는 일종의 '집' 같은 거예요. 보통은 컨테이너 안에서 무슨 짓을 하든 그 집 안에서만 효과가 있고, 옆집(다른 컨테이너)이나 집주인(호스트)에는 영향이 없어야 정상이에요. 그런데 어떤 취약점을 통해 컨테이너 격리를 뚫고 호스트나 다른 컨테이너에 접근하게 되는 걸 '탈출'이라고 부르고, 이건 쿠버네티스 보안에서 가장 치명적인 사고 중 하나예요.

CopyFail은 어떻게 동작하나

핵심 아이디어는 kubectl cp의 내부 동작에 있어요. 이 명령은 사실 단순히 파일을 복사하는 게 아니라, 컨테이너 안에서 tar 명령을 실행해서 파일을 tar 아카이브로 묶어 stdin/stdout으로 주고받는 방식으로 동작해요. 그런데 이 흐름의 어느 지점에 공격자가 영향을 줄 수 있다면, 의도하지 않은 파일이 의도하지 않은 위치에 쓰여질 수 있게 되거든요.

이번 연구에서 지적한 시나리오는 대략 이래요. 공격자가 어떤 식으로든 파드(Pod) 안에 들어와 있다고 가정해요. 권한이 그리 높지 않은 상태죠. 이때 관리자가 디버깅 목적으로 kubectl cp 명령으로 그 파드에서 로그 파일을 꺼내가는 순간이 있다면, 공격자는 심볼릭 링크(symlink)나 경로 조작(path traversal)을 이용해 tar 아카이브 안에 호스트의 임의 경로를 가리키는 항목을 끼워 넣을 수 있어요. 결과적으로 관리자의 워크스테이션이나 노드의 민감한 디렉토리에 공격자의 파일이 쓰여지게 되는 거예요.

쉽게 비유하자면, 우체국에 '제 짐 좀 꺼내가세요' 했는데 짐 안에 '받는 사람 주소를 다시 쓴 가짜 송장'이 들어 있어서, 결국 다른 곳으로 배달되는 상황이라고 보면 돼요. 짐을 보내는 사람의 의도와 무관하게, 받는 쪽 시스템이 송장을 그대로 믿어버리는 게 문제인 거죠.

비슷한 사례, 무엇이 새로운가

쿠버네티스의 kubectl cp 관련 취약점은 사실 이번이 처음은 아니에요. CVE-2019-1002101, CVE-2019-11246, CVE-2019-11249 등 비슷한 결의 path traversal 이슈가 과거에도 여러 번 패치됐어요. 매번 'tar 추출 시 경로 검증을 강화한다'는 식으로 보완해왔는데, 공격 표면이 워낙 미묘해서 우회 경로가 계속 발견되는 영역이에요.

이번 CopyFail은 그 연장선에서, 여전히 남아 있는 엣지 케이스를 파고든 사례예요. 클라이언트 측(kubectl) 검증, 컨테이너 내부의 tar 구현 차이, OS별 심볼릭 링크 해석 방식이 미묘하게 어긋나는 지점을 활용했다고 해요. 단일 버그라기보다는 '신뢰 경계가 모호한 경로'에서 생기는 구조적 이슈에 가깝죠. 한쪽을 막으면 다른 쪽에서 새는, 두더지 잡기 같은 양상이에요.

한국 개발자에게는

쿠버네티스를 운영하는 입장에서 이번 이슈는 몇 가지 점검 포인트를 던져줘요. 첫째, 운영 환경에서 kubectl cp를 가급적 쓰지 말 것. 디버깅이 필요하면 kubectl exec로 컨테이너 안에서 작업을 마치거나, 사이드카 컨테이너에 로그를 모아두고 S3 같은 외부 저장소로 흘려보내는 방식을 쓰는 게 안전해요.

둘째, kubectl 클라이언트 버전을 최신으로 유지해야 해요. 과거 패치된 CVE들도 클라이언트가 옛 버전이면 그대로 노출돼요. 회사 내부에서 운영 PC를 일괄 관리하는 곳이라면 kubectl 버전 정책을 체크해보는 게 좋아요. 사내 위키에 '버전 X 이상만 허용'이라고 적어두기만 해도 효과가 있어요.

셋째, 신뢰할 수 없는 멀티테넌트 환경의 운영 모델 자체를 재검토할 필요가 있어요. SaaS형 쿠버네티스 서비스를 제공한다면, 운영팀의 디버깅 행위가 곧 공격 벡터가 되지 않도록 OPA/Gatekeeper, Kyverno 같은 도구로 정책을 박아두는 걸 권해요. 가능하다면 gVisor, Kata Containers처럼 추가 격리 계층을 두는 방안도 같이 생각해볼 만해요.

마무리

CopyFail이 우리에게 일러주는 진짜 교훈은 '편한 명령어일수록 신뢰 경계를 주의 깊게 보라'는 거예요. kubectl cp 한 줄에는 우리가 잘 안 보던 tar, symlink, path 해석이라는 여러 레이어가 숨어 있고, 그 틈이 곧 공격 표면이 돼요. 여러분 클러스터에서 운영자가 무심코 쓰는 명령어 중, 신뢰 경계를 가로지르는 건 무엇인가요? 한 번쯤 목록을 만들어보는 것도 의미 있는 점검이 될 거예요.