'컨테이너 안이니까 안전하다'는 착각
도커로 서비스를 돌리면서 막연히 '컨테이너 안에 격리돼 있으니 괜찮겠지'라고 생각하기 쉬운데요, 기본 설정의 도커에는 꽤 큰 구멍이 하나 있어요. 도커 데몬이 root 권한으로 돌아간다는 거예요. 컨테이너 안의 프로세스도 별도 설정이 없으면 root로 실행되고요. 이게 왜 문제냐면, 만약 컨테이너 탈출 취약점(컨테이너의 격리를 깨고 호스트로 빠져나오는 버그)이 터지면 공격자가 곧바로 호스트의 root, 그러니까 서버 전체의 관리자 권한을 손에 넣게 되거든요. 사용자를 docker 그룹에 넣어두는 흔한 설정도 사실상 그 사용자에게 root를 준 것과 같아요. 볼륨 마운트 한 번이면 호스트의 어떤 파일이든 만질 수 있으니까요.
루트리스 컨테이너가 뭐냐면
루트리스(rootless) 컨테이너는 이 전제를 뒤집어요. 컨테이너 런타임 자체를 root가 아닌 일반 사용자 권한으로 실행하는 거예요. 핵심 기술은 리눅스의 사용자 네임스페이스인데요, 이게 뭐냐면 컨테이너 안에서 보이는 사용자 ID와 호스트의 실제 사용자 ID를 다르게 매핑하는 기능이에요. 컨테이너 안에서는 자기가 root(UID 0)인 줄 알지만, 호스트에서 보면 십만 번대의 아무 권한 없는 UID인 거죠. 덕분에 최악의 경우 컨테이너가 뚫려도 공격자가 얻는 건 호스트의 힘없는 일반 계정 하나뿐이에요. 피해 범위가 서버 전체에서 계정 하나로 확 줄어드는 거예요. 이 방식의 대표 주자가 팟맨(Podman)인데, 도커와 달리 상시 떠 있는 데몬 없이 명령마다 프로세스가 뜨는 구조라 공격 표면이 더 작고, 명령어가 도커 CLI와 거의 호환돼서 갈아타기도 수월해요. 여기에 systemd의 Quadlet 기능을 쓰면 컨테이너를 일반 리눅스 서비스처럼 부팅 시 자동 시작하고 로그도 journald로 모을 수 있고요.
미리 알아두면 좋은 함정들
물론 공짜는 아니에요. 대표적인 걸림돌이 몇 가지 있는데요. 첫째, 일반 사용자는 1024 미만의 포트를 열 수 없어서 80이나 443 포트를 바로 쓸 수 없어요. 보통 리버스 프록시를 앞에 두거나, sysctl 설정으로 비특권 포트 범위를 낮춰서 해결해요. 둘째, 네트워크 트래픽이 사용자 공간 스택(slirp4netns나 pasta)을 거치기 때문에, 대역폭이 아주 중요한 워크로드라면 성능을 미리 확인해봐야 하고요. 셋째, 볼륨에 쓴 파일의 소유자가 매핑된 UID로 보여서 권한 문제가 생기곤 하는데, 이건 팟맨의 UID 매핑 옵션으로 풀 수 있어요. 여기에 읽기 전용 루트 파일시스템, 불필요한 커널 권한(capability) 제거, 권한 상승 차단 옵션까지 겹겹이 쌓으면 컨테이너 하나하나가 꽤 단단한 상자가 돼요. 뚫릴 구멍을 하나씩 막는 게 아니라, 뚫려도 갈 곳이 없게 만드는 거죠.
한국 개발자에게
이 접근이 특히 빛나는 곳은 혼자 운영하는 서버예요. 홈서버나 VPS에 사이드 프로젝트 여러 개를 올려두는 경우라면, 서비스 하나가 뚫렸을 때 서버 전체가 넘어가는 것과 계정 하나만 내주는 것의 차이가 정말 크거든요. 꼭 팟맨이 아니어도 도커 역시 루트리스 모드를 지원하니 지금 환경에서 바로 시작할 수 있고요. 회사에서도 보안 심사나 규제가 있는 환경이라면 '런타임이 root 권한을 요구하지 않는다'는 사실 자체가 심사에서 유리하게 작용해요. 쿠버네티스 쪽에서도 루트리스 실행이 꾸준히 다듬어지고 있어서, 지금 익혀두면 계속 써먹을 수 있는 지식이에요.
정리하면, 루트리스 컨테이너는 '뚫리지 않게'가 아니라 '뚫려도 피해를 가두게' 설계하는 심층 방어의 실전 사례예요. 여러분의 서버는 컨테이너가 뚫린다는 가정까지 세워두고 계신가요?
🔗 출처: Hacker News