컨테이너가 기본적으로 Root로 실행되면 안 되는 이유는?

컨테이너를 root로 실행하는 것은 프로덕션 환경에서 가장 흔하면서도 가장 위험한 잘못된 구성 중 하나입니다. 모든 워크로드의 공격 표면을 조용히 확대하며, 대부분의 팀은 사고가 발생할 때까지 이를 인식하지 못합니다.

"Root로 실행"의 의미

기본적으로 많은 컨테이너 이미지(특히 최소형 또는 레거시 이미지)는 컨테이너 내부에서 UID 0으로 메인 프로세스를 실행합니다. 컨테이너가 호스트 커널을 다른 컨테이너 및 호스트 자체와 공유하기 때문에, 컨테이너 내부의 root는 완전히 격리된 가상 머신의 root와 같지 않지만 여전히 그래야 할 것보다 훨씬 더 강력합니다. 공격자가 root 소유 컨테이너 내부에서 코드 실행을 달성하면 다음을 얻습니다:

• 의도한 권한과 관계없이 컨테이너에 마운트된 모든 파일에 대한 전체 읽기/쓰기 액세스
• 패키지 설치, 바이너리 수정 또는 애플리케이션 상태 변조 기능
• 커널 또는 런타임 취약점이 악용 가능한 경우 컨테이너 탈출을 위한 훨씬 더 쉬운 경로
• Docker 소켓이나 호스트 파일시스템 경로가 마운트되는 등 잘못 구성된 볼륨과 결합될 때 더 큰 영향력

커널 익스플로잇이 없더라도, 컨테이너 내부의 root 액세스는 모든 애플리케이션 수준 취약점(SSRF, 역직렬화 버그, 임의 파일 쓰기 등)의 영향 범위를 급격히 확대합니다.

오케스트레이션 환경에서 이것이 중요한 이유

Kubernetes 클러스터에서, root 컨테이너가 과도한 Linux 기능 또는 허용적인 보안 컨텍스트와 결합되면 공격자는 다음을 할 수 있습니다:

• 호스트에 영향을 미치는 방식으로 /proc 또는 /sys 수정
• hostPID, hostNetwork 또는 hostIPC가 활성화된 경우 권한 상승
• 마운트된 서비스 계정 토큰을 악용하여 클러스터 전체에 걸쳐 횡적 이동
• privileged: true가 설정되거나 SYS_ADMIN 같은 위험한 기능이 부여된 경우 노드로 탈출

root 사용자 자체가 항상 취약점은 아닙니다. 포함된 침해를 클러스터 전체로 전환하는 것은 root와 과도하게 관대한 커널 기능, 호스트 마운트 또는 네임스페이스 공유의 조합입니다.

실제적인 강화 단계

1. 이미지에 비Root 사용자 설정

Defaults에 의존하지 말고 Dockerfile에서 명시적으로 비root 사용자를 정의하세요:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. 오케스트레이터 수준에서 강제

이미지를 신뢰하지만 말고, 런타임에 정책을 강제하세요. Kubernetes에서 securityContext를 사용하세요:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true는 이미지가 UID 0으로 실행하려고 할 때 파드가 승인 단계에서 실패하도록 하여, 최선을 다하는 규칙이 아닌 확실한 보장을 제공합니다.

3. 불필요한 기능 제거

대부분의 애플리케이션은 컨테이너에 부여되는 기본 Linux 기능 중 어느 것도 필요하지 않습니다. 모든 것을 제거하고 엄격하게 필요한 것만 다시 추가하세요(낮은 포트 바인딩 같은 드문 경우 NET_BIND_SERVICE가 필요할 수 있음).

4. Privileged 모드 및 호스트 네임스페이스 공유 피하기

privileged: true, hostNetwork: true 및 hostPID: true는 매우 특정한 인프라 워크로드(특정 CNI 또는 모니터링 에이전트 같은)를 위해 예약되어야 합니다 — 일반 애플리케이션 컨테이너에는 절대 금지입니다.

5. 정책 도구로 스캔 및 강제

수동 코드 리뷰에 의존하지 말고, 승인 컨트롤러 또는 정책 엔진(예: Kyverno, OPA/Gatekeeper)을 사용하여 이 규칙을 위반하는 배포를 자동으로 거부하세요. 클러스터에 도달하기 전에 root 사용자 이미지를 포착하기 위해 CI의 이미지 스캔과 이것을 함께 사용하세요.

완벽하지 않은 계층화된 방어

Non-root로 실행하는 것이 위험을 완전히 제거하지는 않습니다 — 커널 수준의 컨테이너 탈출은 컨테이너 내부 사용자와 관계없이 존재합니다 — 하지만 낮은 수준의 권한 상승 및 횡적 이동 기법의 거대한 범주를 제거합니다. 읽기 전용 파일시스템, 제거된 기능 및 제한적인 네트워크 정책과 결합하면, 방어 심층 컨테이너 보안 전략에서 가장 저렴하고 효과적인 계층 중 하나를 형성합니다.

클라우드 네이티브 워크로드 강화에 대해 더 깊이 알고 싶으신가요? Cloud security와 DevOps pipeline hardening에 대한 관련 Korra Studio 세그먼트를 탐색하여 방어 심층 전략의 나머지 부분을 구축하세요.