내 도커는 안전할까? 🤔 도커 공식 문서가 말하는 4가지 핵심 보안 영역 파헤치기

컨테이너 기술, 특히 도커(Docker)는 이제 현대적인 개발과 배포 환경의 표준이 되었습니다. 🚀 하지만 편리함과 속도에만 집중하다 보면 '보안'이라는 중요한 숙제를 놓치기 쉽습니다. "컨테이너는 격리되어 있으니 안전하겠지?"라는 막연한 생각은 금물입니다!

https://docs.docker.com/engine/security/

 

 

도커 공식 문서에서는 보안을 검토할 때 반드시 살펴봐야 할 4가지 핵심 영역을 제시합니다. 오늘은 이 네 가지 영역이 구체적으로 무엇을 의미하는지, 그리고 우리는 무엇을 신경 써야 하는지 알기 쉽게 풀어보겠습니다.

---

1. 커널의 본질적인 보안: 네임스페이스와 cgroup 🛡️

도커 컨테이너를 지탱하는 가장 근본적인 기술은 바로 리눅스 커널의 네임스페이스(Namespaces)와 cgroup(Control Groups)입니다. 이 둘이 도커 보안의 첫 번째 방어선입니다.

• 네임스페이스(Namespaces): '보이지 않는 벽'으로 격리하기 🏡 네임스페이스는 하나의 시스템을 여러 개의 격리된 가상 공간으로 나누는 기술입니다. 컨테이너가 마치 독립적인 OS처럼 보이게 만드는 마법의 핵심이죠. 각 컨테이너는 자신만의 네임스페이스를 할당받아 다른 컨테이너나 호스트 시스템을 볼 수 없습니다.
  • PID Namespace: 컨테이너 안에서는 자신의 프로세스만 보입니다. ps 명령어를 쳐도 호스트의 다른 프로세스는 보이지 않죠.
  • NET Namespace: 각 컨테이너는 자신만의 네트워크 스택(IP 주소, 라우팅 테이블, 포트)을 가집니다. 마치 별도의 랜카드를 가진 것처럼 네트워크가 완벽히 분리됩니다.
  • MNT Namespace: 컨테이너는 독립된 파일 시스템을 가집니다. 호스트의 파일 시스템에 직접 접근할 수 없어 파일 시스템 수준의 격리가 이루어집니다.
  • 이 외에도 UTS(호스트명), IPC(프로세스 간 통신), User(사용자) 네임스페이스가 격리를 돕습니다.
• cgroup(Control Groups): '자원 사용량' 통제하기 📊 네임스페이스가 '공간'을 분리했다면, cgroup은 '자원'을 제한합니다. 특정 컨테이너가 호스트의 모든 CPU나 메모리를 독차지해서 시스템 전체를 마비시키는 '자원 독점 공격(Noisy Neighbor)'을 막는 역할을 합니다.
  • 메모리 제한: 컨테이너가 사용할 수 있는 최대 메모리 양을 정합니다.
  • CPU 제한: 컨테이너에 CPU 코어의 특정 부분만 할당하거나 사용률을 제한할 수 있습니다.
  • I/O 제한: 디스크 입출력 속도를 제한하여 특정 컨테이너가 디스크 성능을 저하하는 것을 방지합니다.

쉽게 말해, 네임스페이스는 각 컨테이너에 '독립된 방'을 주는 것이고, cgroup은 그 방에 공급되는 '전기 및 수도 사용량을 계량기로 제어'하는 것과 같습니다. 이 두 가지가 없다면 컨테이너는 성립할 수 없습니다.

---

2. Docker 데몬 자체의 공격 표면 👿

도커의 모든 것을 관리하는 '중앙 관제실'이 바로 도커 데몬(Docker Daemon, dockerd)입니다. 이미지를 만들고, 컨테이너를 실행하고, 네트워크를 설정하는 모든 작업이 데몬을 통해 이루어집니다. 하지만 강력한 권한은 곧 강력한 위험을 의미합니다.

• 가장 큰 위협: 루트(root) 권한 전통적으로 도커 데몬은 루트 사용자로 실행됩니다. 만약 공격자가 어떤 방법으로든 도커 데몬을 제어할 수 있게 된다면, 그것은 호스트 시스템의 루트 권한을 탈취하는 것과 같습니다. 컨테이너를 넘어 호스트 전체가 장악되는 최악의 시나리오가 발생할 수 있죠.
• 주요 공격 경로: 도커 소켓 (/var/run/docker.sock) 도커 CLI가 데몬에게 명령을 내릴 때 사용하는 통신 채널이 바로 이 유닉스 소켓 파일입니다. 만약 컨테이너를 생성할 때 이 소켓 파일을 컨테이너 내부에 마운트(-v /var/run/docker.sock:/var/run/docker.sock)한다면 어떻게 될까요? 컨테이너 내부의 공격자가 호스트의 도커 데몬을 마음대로 조종하여 새로운 컨테이너를 띄우거나 다른 컨테이너를 공격할 수 있게 됩니다. 이는 집에 도둑이 들어왔는데, 그에게 집 전체의 보안 시스템 제어권을 넘겨주는 것과 같습니다. 🔑

핵심은, 도커 데몬은 막강한 권한을 가진 '배의 선장' 🚢과 같습니다. 선장실(데몬)이 공격받지 않도록 API 접근 제어를 철저히 하고, 도커 소켓을 함부로 노출하지 않는 것이 매우 중요합니다. (최근에는 루트 권한 없이 데몬을 실행하는 Rootless 모드도 대안으로 떠오르고 있습니다.)

---

3. 컨테이너 구성 프로필의 허점 🔓

아무리 커널이 튼튼하고 데몬이 안전해도, 우리가 직접 실행하는 컨테이너의 설정에 구멍이 있다면 모든 것이 무용지물입니다.

도커는 기본적으로 안전한 설정을 제공하지만, 사용자가 편의를 위해 위험한 옵션을 남용하는 경우가 많습니다.

• 최악의 옵션: --privileged 이 옵션을 사용하면 컨테이너는 거의 모든 보안 격리 기능(네임스페이스, cgroup, Seccomp 등)을 무시하고 호스트의 주요 장치에 접근하는 등 막강한 권한을 갖게 됩니다. 컨테이너가 아니라 사실상 호스트에서 직접 실행되는 프로세스와 다름없어지죠. 정말 특별한 경우가 아니라면 절대 사용해서는 안 됩니다.
• 위험한 설정들 ⚠️
  • 호스트 네트워크 공유 (--net=host): 컨테이너의 네트워크 격리를 포기하고 호스트의 네트워크를 그대로 사용하게 되어 보안에 취약해집니다.
  • 민감한 디렉토리 마운트: 호스트의 / 나 /etc 같은 중요 디렉토리를 컨테이너에 마운트하면 컨테이너 내부에서 호스트의 중요 파일들을 수정하거나 탈취할 수 있습니다.
  • 컨테이너 내에서 root 사용자로 실행: Dockerfile에서 USER 지시어를 사용해 일반 사용자로 프로세스를 실행하는 것이 훨씬 안전합니다.

결국, 컨테이너 보안은 사용자에게 달려 있습니다. '최소 권한의 원칙'에 따라 컨테이너가 작업에 필요한 딱 그만큼의 권한만 갖도록 설정하는 것이 중요합니다. 손님에게 안방 열쇠가 아닌 손님방 열쇠만 주는 것과 같은 이치입니다.

---

4. 커널의 "강화" 보안 기능 👮‍♂️

앞서 설명한 네임스페이스와 cgroup이 기본 방어선이라면, 지금부터 소개할 기능들은 추가적인 **'특수 보안 시스템'**입니다. 이들은 만약의 사태에 대비한 다중 방어 체계를 구축해 줍니다.

• AppArmor & SELinux (접근 제어) 이들은 강제적 접근 제어(MAC, Mandatory Access Control) 시스템입니다. 쉽게 말해, 각 애플리케이션(컨테이너)마다 "너는 이 파일만 읽을 수 있고, 저 파일은 쓸 수 없으며, 이 네트워크 포트만 사용할 수 있어" 와 같은 '행동 규칙 프로필'을 강제로 적용하는 것입니다. 도커는 기본적으로 AppArmor 프로필을 생성하여 컨테이너에 적용합니다. 만약 컨테이너 내부의 앱이 해킹당하더라도, 이 프로필에 정의되지 않은 악의적인 행동(예: 시스템 파일 수정)은 커널 수준에서 차단됩니다.
• Seccomp (시스템 콜 필터링) 🚨 Seccomp는 애플리케이션이 커널에 요청할 수 있는 시스템 콜(System Call)의 목록을 제한하는 기능입니다. 시스템 콜은 앱이 파일 열기, 네트워크 통신 등 커널의 기능을 사용하기 위해 보내는 요청입니다. 도커는 기본 Seccomp 프로필을 통해 300개가 넘는 시스템 콜 중 컨테이너에 굳이 필요 없는 위험한 시스템 콜(예: reboot, kexec_load 등) 약 40여 개를 미리 차단합니다. 이를 통해 공격자가 사용할 수 있는 공격 루트를 원천적으로 줄여버리는 효과가 있습니다.

즉, 이러한 강화 기능들은 컨테이너가 해킹당했다는 최악의 상황을 가정하고, 공격자가 더 큰 피해를 주지 못하도록 마지막 방어선 역할을 수행하는 든든한 경호원들입니다.

✨ 마치며

지금까지 도커 공식 문서가 강조하는 4가지 보안 영역을 살펴보았습니다. 정리하자면 도커 보안은 다음과 같은 계층적 구조를 가집니다.

1. 기반 계층: 커널의 네임스페이스와 cgroup으로 컨테이너를 격리하고 자원을 제어한다.
2. 관리 계층: 도커 데몬의 접근을 철저히 통제하여 호스트 전체의 보안을 지킨다.
3. 애플리케이션 계층: 컨테이너 자체의 설정을 안전하게 구성하여 불필요한 권한을 주지 않는다.
4. 강화 계층: AppArmor, Seccomp 등으로 만일의 사태에 대비한 추가 방어막을 친다.

도커 보안은 어느 한 가지만 잘한다고 해결되는 것이 아니라, 모든 계층에서 종합적으로 접근해야 하는 중요한 과제입니다. 오늘 살펴본 네 가지 영역을 항상 기억하며, 더욱 안전하고 신뢰할 수 있는 컨테이너 환경을 만들어가시길 바랍니다!

---