컨테이너의 Docker 데몬 소켓 접근 점검

일반 애플리케이션에 호스트 Docker 데몬 소켓을 제공하지 마세요.

설명

Docker 데몬 소켓을 컨테이너에 마운트하고 프로세스가 통신할 수 있게 하면 호스트의 컨테이너 관리 기능에 접근할 수 있습니다. 데몬 권한에 따라 호스트 파일 접근이나 특권 컨테이너 생성으로 이어질 수 있으므로 일반 애플리케이션에는 제공하지 않는 것이 안전합니다.

실제 영향은 소켓 존재 여부, 프로세스의 접근 권한과 데몬 구성에 따라 달라집니다. Kubernetes의 모든 컨테이너 런타임이 Docker 소켓을 사용하는 것은 아닙니다.

잠재적 영향

  • 침해된 애플리케이션이 Docker API를 통해 다른 컨테이너나 호스트 자원에 접근할 수 있습니다.
  • 데몬의 강한 권한이 컨테이너 격리를 약화시키고 노드 침해로 이어질 수 있습니다.

해결 방법

  • 필요하지 않은 Docker 소켓의 host_path 볼륨과 volume_mount를 제거하세요. 읽기 전용 마운트만으로 Docker API의 변경 작업을 차단할 수 있다고 가정하지 마세요.
  • 빌드·관리 작업에 데몬 접근이 꼭 필요하다면 일반 서비스와 분리하고 허용되는 작업과 실행 주체를 제한하세요. 호스트 마운트와 특권 사용을 정책으로 통제하세요.

예시

변경 전은 실제 Docker 소켓이 있는 노드에서 볼륨과 마운트를 연결한 예제입니다. 이미지가 소켓 접근을 필요로 하는 것은 아닙니다. 실제 배포에는 유지보수되는 이미지를 사용하세요.

변경 전

hcl
resource "kubernetes_pod" "pod" {
  metadata {
    name = "terraform-example"
  }

  spec {
    volume {
      name = "docker-socket"
      host_path {
        path = "/var/run/docker.sock"
        type = "Socket"
      }
    }

    container {
      image = "nginx:1.7.9"
      name  = "example"
      volume_mount {
        name       = "docker-socket"
        mount_path = "/var/run/docker.sock"
      }
    }
  }
}

변경 후

hcl
resource "kubernetes_pod" "pod" {
  metadata {
    name = "terraform-example"
  }

  spec {
    container {
      image = "nginx:1.7.9"
      name  = "example"
    }
  }
}

설명:

  • 변경 전: 컨테이너에 호스트 Docker 소켓을 마운트합니다. 프로세스의 실제 접근 권한도 영향을 줍니다.
  • 변경 후: 필요하지 않은 소켓 볼륨과 마운트를 제거합니다.

참조