Docker scratch image from a Security perspective
최근 도커 관련해서 테스트하던 중 Scratch 라는 이미지를 보게 되었습니다. 개인적으론 처음보는 이미지인데, 특이하게도 보편적인 OS에서 사용되는 명령어부터 여러가지 중요한 바이너리나 설정까지 없는 독특한 이미지였죠. 찾다보니 생각보다 재미있는 이미지여서 관련 내용과 저의 생각을 약간 더해서 글을 작성해봅니다.
Docker Scratch image
What is it?
Scratch는 Docker에서 만든 가장 Base가 되는 빈 이미지입니다. 정확히는 바이너리만 실행할 수 있는 최소한의 이미지라고 생각하시면 됩니다.
Dockerhub에도 이렇게 설명되어 있습니다.
This image is most useful in the context of building base images (such as debian and busybox) or super minimal images (that contain only a single binary and whatever it requires, such as hello-world).
https://hub.docker.com/_/scratch
Why use this? and How to use?
자 이렇게 아무것도 없는 이미지를 왜 사용하는 걸까요? 우선 위 Dockerhub에 있는 설명을 보면 base image를 만드는데 유용하다고 합니다. 그래서 주로 사용되는 debian-buster, alpine 등등의 이미지는 이를 기초로 만들어졌다고 생각하시면 됩니다.
이유를 생각해보면, 아무것도 없기 때문에 실행할 바이너리만 있다면 가장 가벼운 이미지를 만들 수 있습니다. 사용하는 방법은 다른 이미지와 동일합니다. 그냥 scratch 이미지를 기반으로 Dockerfile을 작성해주시면 됩니다.
FROM scratch
하나 예시를 들어서 go project라고 가정하고 scratch 기반의 이미지를 만들어봅시다. muilti-stage build를 이용해 golang:latest에서 go build한 바이너리를 만들어주고, scrach 이미지로 옮겨와서 cmd로 지정해줍니다. 결과적으론 scatch에 실행할 바이너리만 남기 때문에 엄청 가벼운 이미지가 탄생합니다.
FROM golang:latest AS builder
WORKDIR /app
COPY . .
RUN go build . -o testapp
FROM scratch
COPY --from=builder /app/testapp .
CMD ['testapp']
하나 주의해야할 점은 말 그대로 아무것도 없는 이미지이기 때문에 바이너리에 포함되지 않은 라이브러리/패키지/외부 명령어 등 의존성을 고려할 수 밖에 없습니다. 그래서 빌드 단계에서 최대한 많은 정보를 포함하여 빌드를 해줘야합니다.
From a security perspective
자 그럼 보안관점에서는 어떤 특징이 있을까요? 당장 생각나는건 3가지입니다. 😃
Security Hardening
첫번째로 하드닝적인 부분입니다. 대부분(?)의 기업은 시스템에서 사용되고 있는 설정이나 패키지등의 Security Hardening을 진행하고 있고, 도커 이미지 또한 예외는 아닐겁니다.
물론 의존성으로 인해 구성 자체가 어렵지만, scrach 위에서 동작하고 실행에 필요한 바이너리만 있는 경우 OS, 타 어플리케이션에서의 잘못된 설정을 피해갈 수 있어 조금 더 안전상 상태가 될 것이라 생각됩니다.
Defening supply chain attack
도커 이미지를 서비스에 맞게 구성하지만, 보통 base가 되는 이미지는 외부에서 가져오는 경우가 많습니다. 물론 이 또한 supply chain attack을 방지하기 위해 기업에서 이미지의 안정성 검사라던지 여러가지 요소로 이미지 내 위협요소를 탐지하려고 할겁니다.
이러한 관점에서 보면 가장 최소 단위의 scratch 이미지는 외부 이미지 내 위협요소가 포함된 경우가 상대적으로 적을 수 밖에 없겠죠. (base 이미지 자체가 훼손된게 아니라면, 중간에 외부의 요소가 개입할 부분이 없을거에요. base 이미지 자체가 훼손됬다는건 모든 Docker 이미지에 문제가 있을거란 이야기이도 하구요)
Isolated container
음 사실 컨테이너 자체가 어느정도 격리되어 있는 환경인건 맞는데, 도커 자체의 문제로 호스트로 진입하는 형태의 취약점이 없는건 아닙니다. 다만 scatch 이미지의 경우 아무것도 없는 상태로 인해서 상대적으로 그러한 취약점이 트리거될 수 있는 확률이 낮다는 장점이 있겠죠.