Docker 격리: 첫 번째 방어선

컨테이너는 마법이 아니에요 (하지만 크게 도움돼요)

🔄 Quick Recall: 이전 레슨에서 OWASP, AWS 스코핑 매트릭스, Rule of Two를 사용해 위협 모델을 구축했어요. Docker 격리가 과도한 에이전시(A2)와 도구 오용(A1)에 대한 첫 번째 방어임을 확인했어요. 이제 구현해요.

SecurityScorecard가 인터넷에 노출된 135,000개 이상의 OpenClaw 인스턴스를 발견했어요. 기본 설정이 모든 네트워크 인터페이스에 바인딩해요. Docker 설정 하나의 변경 — localhost에 바인딩 — 만으로 모든 노출을 예방할 수 있었어요.

이 레슨의 핵심이에요: 가장 큰 보안 임팩트를 가진 구체적이고 실용적인 변경.

이 레슨을 마치면 다음을 할 수 있어요:

• AI 에이전트 특화 5가지 하드닝 플래그로 Docker 컨테이너를 구성
• 표준 컨테이너에서 MicroVM까지의 격리 스펙트럼을 설명

Docker가 실제로 하는 것

Docker는 두 가지 Linux 커널 기능을 사용해 격리된 환경을 만들어요:

네임스페이스는 컨테이너에 자체 시스템 뷰를 제공해요 — 자체 프로세스 ID, 네트워크 인터페이스, 파일시스템 마운트, 사용자 ID. 컨테이너는 머신에 혼자 있다고 생각해요.

Cgroup은 컨테이너가 사용할 수 있는 호스트 리소스를 제한해요 — CPU, 메모리, 디스크 I/O. 컨테이너가 시도해도 모든 RAM을 소비할 수 없어요.

함께하면 경계를 만들어요. 에이전트는 안에서 실행돼요. 여러분의 개인 파일, 다른 애플리케이션, 시스템 설정은 밖에 있어요. 손상된 에이전트는 경계 안의 것만 파괴할 수 있어요.

한계: 네임스페이스와 cgroup 모두 호스트 커널에 의존해요. 커널 취약점이 있으면 공격자가 컨테이너를 완전히 탈출할 수 있어요.

5가지 하드닝 플래그

Composio의 RAK Framework(Root, Agency, Keys)와 Docker의 자체 보안 가이드가 AI 에이전트에 가장 중요한 5가지 플래그에서 수렴해요:

플래그 1: --read-only

컨테이너의 파일시스템을 읽기 전용으로 만들어요. 에이전트가 시스템 디렉토리에 쓰거나, 자체 설정을 수정하거나, 영구 백도어를 만들 수 없어요.

# docker-compose.yml
services:
  agent:
    read_only: true
    tmpfs:
      - /tmp
      - /app/data

에이전트가 합법적으로 써야 하는 디렉토리에는 쓰기 가능한 tmpfs(인메모리) 볼륨을 마운트해요. 나머지는 동결돼요.

중요한 이유: Zenity 연구에서 악성 스킬이 SOUL.md(에이전트의 메모리 파일)에 쓰기로 지속될 수 있음을 보여줬어요. 읽기 전용 파일시스템이 이를 방지해요.

플래그 2: --cap-drop=ALL

모든 Linux 능력을 제거해요. 에이전트는 상승된 권한 없이 실행돼요.

services:
  agent:
    cap_drop:
      - ALL

에이전트가 특정 능력이 필요하면(AI 에이전트에서는 드문 경우) cap_add로 명시적으로 추가하세요. 기본값을 그대로 두지 마세요.

플래그 3: 비루트 사용자

기본적으로 Docker 컨테이너 안의 프로세스는 root로 실행돼요. 공격자가 컨테이너를 탈출하면 호스트에 root로 착지해요.

services:
  agent:
    user: "1000:1000"

중요한 이유: Argus Security 감사에서 OpenClaw의 파일 권한이 0o600(소유자 전용)으로 설정되었지만 프로세스가 root로 실행되어 권한 제한이 의미 없었음을 발견했어요.

✅ Quick Check: AI 에이전트 컨테이너가 기본 능력으로 root로 실행돼요. 공격자가 컨테이너 탈출 취약점을 발견해요. 무엇을 얻나요? (답: 상승된 Linux 능력을 가진 호스트 머신의 root 접근. 비루트 사용자와 –cap-drop=ALL로 실행했다면 공격자는 능력이 없는 비권한 사용자로 호스트에 착지 — 피해를 극적으로 제한해요.)

플래그 4: 리소스 제한

손상된(또는 환각하는) 에이전트가 모든 CPU와 메모리를 소비해 머신을 서비스 거부할 수 있어요.

services:
  agent:
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: "1.0"
        reservations:
          memory: 512M
          cpus: "0.5"

에이전트를 2GB RAM과 1 CPU 코어로 제한해요. 초과하면 Docker가 프로세스를 종료해요. 머신은 반응 가능한 상태를 유지해요.

플래그 5: 네트워크 제한

localhost에 바인딩하면 원격 접근을 차단해요. 네트워크 격리로 더 나아갈 수 있어요:

services:
  agent:
    ports:
      - "127.0.0.1:18789:18789"  # Localhost only
    networks:
      - agent-internal

networks:
  agent-internal:
    internal: true  # 인터넷 접근 불가

네트워크에 internal: true를 설정하면 컨테이너가 인터넷에 전혀 도달할 수 없어요. 치명적 삼각 편대의 한 축(외부 통신)을 제거하고 자격증명 유출을 방지해요.

✅ Quick Check: 에이전트를 위해 내부 Docker 네트워크를 설정했는데 에이전트가 특정 API 하나를 호출해야 해요. 가장 안전한 접근은? (답: 해당 API 도메인과 포트만 허용하는 HTTP 프록시 또는 방화벽 규칙을 사용해요. 에이전트는 여전히 임의 인터넷 목적지에 도달할 수 없지만 필요한 API는 작동해요. 네트워킹에 적용된 최소 권한 원칙이에요.)

완전한 하드닝 설정

5가지 플래그를 모두 결합한 프로덕션 레디 docker-compose.yml:

version: "3.8"
services:
  agent:
    image: openclaw/openclaw:latest
    read_only: true
    user: "1000:1000"
    cap_drop:
      - ALL
    ports:
      - "127.0.0.1:18789:18789"
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: "1.0"
    tmpfs:
      - /tmp
      - /app/data
    environment:
      - GATEWAY_TOKEN=${GATEWAY_TOKEN}
    volumes:
      - ./agent-data:/app/workspace:rw
    networks:
      - agent-net

networks:
  agent-net:
    internal: true

격리 스펙트럼

Docker만이 유일한 옵션은 아니에요:

대부분의 개인 사용에서 하드닝 플래그를 갖춘 Docker가 실용적 권장 사항이에요. 레슨 1에서 문서화된 가장 흔한 공격을 차단하면서 설정과 유지가 쉬워요.

핵심 정리

• 5가지 하드닝 플래그: --read-only, --cap-drop=ALL, 비루트 사용자, 리소스 제한, 127.0.0.1 바인딩
• 읽기 전용 파일시스템이 영구 백도어(SOUL.md 포이즈닝)를 방지해요
• 능력 제거로 컨테이너 탈출 시 공격자가 상승된 권한을 전혀 얻지 못해요
• localhost 바인딩만으로 135,000개 이상의 노출 인스턴스를 예방할 수 있었어요
• 내부 네트워크가 외부 통신을 제거 — 치명적 삼각 편대의 한 축
• MicroVM이 컨테이너보다 강력한 격리를 제공하지만 하드닝된 Docker가 실용적 기준선

다음 레슨

에이전트가 격리되었어요. 하지만 격리만으로는 부족해요 — 컨테이너 안에서 에이전트가 할 수 있는 것도 제어해야 해요. 다음 레슨에서 권한 경계와 자격증명 격리를 다뤄요: 최소 권한, 범위 제한 토큰, API 키가 에이전트에 직접 닿지 않게 하는 방법.