docker.sock를 차단했지만, 컨테이너는 여전히 안전하지 않습니다.

Source: Dev.to

지난 2주 동안 전체 런타임‑이스케이프 실험실을 구축했습니다 — 다섯 가지 공격 시나리오, 자동 방어 스크립트, Falco 규칙 등 모두 포함했습니다. 시나리오 1(docker.sock 마운팅)은 이미 DZone의 심층 분석으로 다루어졌습니다. 모두가 그 이야기를 알고 있죠.

하지만 시나리오 3과 4가 실제로 저를 밤새도록 잠 못 들게 했습니다. 시끄럽고 극적인 것 때문이 아니라, 조용하기 때문입니다. 팀이 실행하는 검사들을 통과하고, docker inspect에서도 정상적으로 보이며, 공격자에게 호스트로 가는 경로를 제공합니다.

이 글에서는 다음을 다룹니다:

• 감사 사각지대 – 대부분의 스캐너를 빠져나가는 단일 기능.
• 권한 상승 체인 – --privileged 플래그 없이도 가능한 두 컨테이너 권한 상승.

Source: …

감사 사각지대: CAP_SYS_ADMIN

스캐너가 놓치는 이유

대부분의 Docker 보안 체크리스트는 Privileged: true만 확인합니다. 플래그가 false이면 초록색 체크마크를 주고 넘어갑니다.

--privileged 없이 CAP_SYS_ADMIN만 부여해도 컨테이너는 거의 모든 특권 모드와 동일한 권한을 가집니다: 파일시스템 마운트, 네임스페이스 조작, 그리고 일부 커널 설정에서는 호스트 전체로 탈출까지 가능합니다. 감사 로그에서는 다른 권한 목록 중 하나로 표시될 뿐, 위험 신호로 보이지 않습니다.

감사 격차 – 자동 스캔에서 일관되게 놓치는 단일 권한으로, 스캐너가 Privileged 불리언만을 검사하도록 튜닝돼 있어 개별 권한이 실제로 할 수 있는 일을 놓칩니다.

실제 모습

# 스캐너가 보는 내용
docker inspect my-container | jq '.[] | {Privileged: .HostConfig.Privileged}'
# 출력:
# { "Privileged": false }

# 예시 탐지 규칙 (예시용)
condition: >
  container.image.digest != "" and
  evt.type = container_start and
  ka.verb = create and
  container.privileged = true and
  container.mount.dest in ("/etc", "/root", "/var/run")
output: >
  Escalation chain: socket container spawned privileged mount
  (container=%container.name image=%container.image)
priority: CRITICAL

이 규칙은 개별 컨테이너가 아니라 패턴을 포착합니다. 사고방식의 전환이 차이를 만들죠.

Source:

실습 랩

다섯 개 시나리오(여기서 다루는 두 개 포함)는 모두 오픈소스 랩 저장소에 있습니다. 각 시나리오에는 다음 파일이 포함됩니다:

• demo.sh – 공격을 실행하여 직접 확인할 수 있습니다
• defense.sh – 탐지 아티팩트(Falco 규칙, 감사 스크립트)를 생성합니다
• validate.sh – 방어가 실제로 작동하는지 검증합니다
• cleanup.sh – 모든 것을 깔끔하게 정리합니다

git clone https://github.com/opscart/docker-security-practical-guide
cd labs/09-runtime-escape

# 시나리오 3 실행 (CAP_SYS_ADMIN 감사 격차)
cd scenario-3-sys-admin
chmod +x *.sh && ./demo.sh

# 시나리오 4 실행 (호스트 마운트 권한 상승 체인)
cd ../scenario-4-host-mount
chmod +x *.sh && ./demo.sh

Docker Desktop(macOS/Windows) 및 Linux에서 동작합니다. README에는 VM 레이어에서 동작이 다르게 나타나는 부분에 대한 Docker Desktop‑전용 참고 사항이 포함되어 있습니다.

실제로 해야 할 일

두 가지. 모두 5분이면 됩니다.

1. 위에서 언급한 capability audit를 여러분의 환경에 실행하세요. SYS_ADMIN, SYS_PTRACE, SYS_MODULE을 찾아보세요. 발견하면, 왜 존재하는지 추적하세요. 절반 정도는 아무도 기억하지 못합니다.

2. Escalation‑chain 패턴을 감사하세요: docker.sock이 마운트된 컨테이너와 host‑path 바인드 마운트가 있는 컨테이너가 같은 환경에 있는 경우. 두 가지가 모두 존재한다면—서비스가 서로 무관하더라도—공격 표면이 존재합니다.

관련 읽을거리

• Docker Runtime Escape:
  Why Mounting docker.sock Is Worse Than Running Privileged Containers — 시나리오 1, 소켓 탈출 체인 (DZone)

• Docker Security:
  6 Practical Labs From Audit to AI Protection — 랩 01–06, 기초 (DZone)

• Advanced Docker Security:
  From Supply Chain Transparency to —Network Defense — 랩 07–08 (DZone)

실험실 저장소에 모든 것이 포함되어 있습니다:
github.com/opscart/docker-security-practical-guide

연결

• 블로그:
• GitHub:
• LinkedIn: