2026년에 피해야 할 주요 Docker 보안 실수

눈에 띄는 문제 없이 몇 달 동안 프로덕션 환경에서 Docker를 실행할 수 있습니다. 컨테이너가 시작되고 앱이 응답하며 아무 문제도 발생하지 않습니다. 그러면 하나의 노출된 포트 또는 하나의 잘못 구성된 권한이 공격자가 획득할 필요가 없는 발판을 만듭니다. 대부분의 Docker 보안 실수는 문제가 발생하기 전까지는 실수처럼 보이지 않습니다.

이 문서에서는 컨테이너 환경을 위험에 빠뜨리는 특정 구성, 각 구성이 공격자에게 허용하는 내용을 다루고, 현재 자체 설정에 대해 실행할 수 있는 체크리스트로 마무리합니다.

Docker 보안이 보기보다 어려운 이유

컨테이너는 고립된 느낌을 줍니다. 하나를 시작하면 자체 프로세스 공간이 실행되고 내부에는 다음 컨테이너가 존재하지 않습니다. 당신은 고립을 느끼지만 그것은 단지 부분적일 뿐입니다. 컨테이너는 호스트의 커널을 공유합니다. 이는 컨테이너 내부의 프로세스가 특정 조건에서 호스트 시스템에 완전히 도달할 수 있음을 의미합니다.

Docker 배송은 프로덕션 강화가 아닌 개발자 편의를 위해 구성됩니다. 루트 액세스가 켜져 있습니다. 모든 포트는 모든 인터페이스에 바인딩 가능합니다. 런타임 모니터링이 없습니다. 대부분의 개발자는 이러한 설정을 수락하고 컨테이너를 배송한 후 계속 진행합니다. 이는 시작하기 위한 합리적인 접근 방식입니다. 완성된 보안 태세가 아닙니다.

에 따르면 Red Hat의 2024년 Kubernetes 보안 현황 보고서, 67%의 조직이 컨테이너 또는 Kubernetes 보안 문제로 인해 애플리케이션 배포를 지연하거나 느리게 했습니다. 그 마찰은 일반적으로 공격으로 인한 것이 아닙니다. 컨테이너 설정에 내장되지 않은 강화가 필요하다는 사실을 발견한 팀에서 나온 것입니다.

개발자의 로컬 컴퓨터에서와 동일한 구성으로 프로덕션 환경에서 실행되는 컨테이너를 자주 볼 수 있습니다. Docker 보안 실수는 무언가가 감사되거나 실패할 때까지 눈에 띄는 증상 없이 조용히 복합되는 경향이 있습니다.

이러한 격차를 만드는 실수는 구성 수준부터 구체적이고 예측 가능하며 대부분 피할 수 있습니다.

일반적인 Docker 구성 실수

대부분의 컨테이너 침해는 제로데이 공격으로 시작되지 않습니다. 네트워크 노출이나 권한 범위에 대해 많이 생각하지 않고 첫날부터 구성 세트로 시작합니다.

기본 Docker 설정은 작동하도록 구축되었습니다. 기능과 보안 사이의 격차는 Docker 컨테이너 보안 위험이 누적되는 곳입니다. 특히 배포되고 다시 방문되지 않는 자체 호스팅 설정에서는 더욱 그렇습니다.

우리는 이러한 패턴을 자주 볼 수 있습니다. 즉, 초기 배포 시와 정확히 동일하게 포트 바인딩, 사용자 설정 및 네트워크 구성을 갖춘 공용 IP 서버의 컨테이너입니다.

컨테이너를 루트로 실행

사용자를 지정하지 않고 Docker 컨테이너를 시작하면 루트로 실행됩니다. 이는 애플리케이션을 포함하여 컨테이너 내부의 모든 프로세스가 컨테이너의 네임스페이스 내에서 루트 수준 권한을 가짐을 의미합니다.


컨테이너 내부의 루트는 호스트의 루트와 동일하지 않지만 분리가 절대적이지는 않습니다. 잘 문서화된 runc CVE-2019-5736 및 유사한 런타임 결함과 같이 런타임을 대상으로 하는 권한 상승 악용은 루트 컨테이너 프로세스가 성공해야 하는 경우가 많습니다.

루트가 아닌 컨테이너는 이러한 익스플로잇이 의존하는 루트 프로세스 요구 사항을 제거하여 해당 취약성 클래스에 대한 공격 표면을 크게 줄입니다. 하지만 컨테이너 탈출 위험을 완전히 제거하지는 않습니다.

Dockerfile에 USER 지시문을 추가하면 이 문제가 해결됩니다. 일부 공식 이미지는 USER 지시어를 사용하여 활성화할 수 있는 권한 없는 사용자와 함께 제공되지만, 대부분은 기성 앱 사용자 없이 여전히 루트로 기본 설정되어 있습니다. 이러한 경우 Dockerfile로 전환하기 전에 Dockerfile에서 사용자를 생성합니다. 대부분의 자체 호스팅 설정의 경우 이 단일 변경으로 전체 에스컬레이션 위험 범주가 제거됩니다.

너무 많은 포트를 공용 인터넷에 노출

Docker를 사용하여 포트를 게시하면 Docker는 자체 iptables 규칙을 직접 작성합니다. 이러한 규칙은 호스트 수준 방화벽 규칙보다 먼저 실행됩니다. 이것은 커뮤니티에서 보고된 잘 알려진 행위 그리고 Docker의 패킷 필터링 가이드에 문서화되어 있습니다., 잘못된 구성이 아니라 UFW 및 유사한 도구가 Docker가 이미 연 것을 차단하지 않는다는 의미입니다.

Docker는 많은 Linux 호스트에서 UFW 및 방화벽 기본값을 우회하여 iptables에 직접 씁니다. 이는 방화벽이 구성된 것처럼 보이더라도 0.0.0.0에 바인딩된 포트에 공개적으로 연결할 수 있음을 의미합니다. 클라우드 보안 그룹과 DOCKER-USER 체인 규칙은 해당 트래픽을 계속 차단할 수 있으므로 실제 노출은 특정 네트워크 설정에 따라 달라집니다.

가능한 경우 서비스를 127.0.0.1에 바인딩하고, 공개 트래픽을 역방향 프록시를 통해 라우팅하고, 실제로 외부 액세스가 필요한 항목만 게시하세요. 역방향 프록시는 호스트 외부에서 노출되는 것을 제어하는 ​​가장 안정적인 방법입니다.

컨테이너 간 네트워크 격리 무시

해당 네트워크의 모든 컨테이너는 제한 없이 다른 컨테이너에 도달할 수 있습니다. 기본 브리지는 이를 공유하는 컨테이너 간에 트래픽 필터링을 적용하지 않으며 대부분의 설정에서는 해당 구성을 변경하지 않습니다.

컨테이너 하나가 손상되면 개방형 통신이 측면 이동 경로가 됩니다. 프런트엔드 컨테이너는 액세스가 의도되지 않은 경우에도 동일한 기본 브리지 네트워크에 있는 데이터베이스, 내부 API 또는 기타 항목에 연결할 수 있습니다.

사용자 정의 네트워크를 사용하면 어떤 컨테이너가 통신할 수 있는지 명시적으로 제어할 수 있지만 모든 서비스에서 공유하는 단일 사용자 지정 네트워크는 여전히 무료 컨테이너 간 트래픽을 허용합니다. 실제 격리를 위해서는 서로 통신해서는 안 되는 서비스를 별도의 네트워크에 배치해야 합니다. 기본 브리지를 끄는 것은 결승선이 아니라 시작점입니다.

Docker 소켓 내려다보기

/var/run/docker.sock의 Docker 소켓은 전체 Docker 엔진에 대한 제어 인터페이스입니다. 이를 컨테이너에 마운트하면 해당 컨테이너가 호스트에서 실행되는 데몬에 대한 직접 API 액세스를 제공합니다.

해당 액세스를 통해 컨테이너는 새 컨테이너를 시작하고, 호스트 디렉터리를 마운트하고, 실행 중인 컨테이너를 검사 및 수정하고, 호스트 시스템을 효과적으로 제어할 수 있습니다. 공격 표면은 호스트의 루트와 동일하므로 소켓 액세스가 필요한 도구는 신중하게 평가할 가치가 있습니다.

대부분의 사용 사례에는 범위가 지정된 API 또는 도커 관리 도구 소켓 액세스가 필요하지 않습니다. Docker-in-Docker는 보안과 운영상의 절충안을 갖고 있으며 직접적인 대체 수단은 아닙니다.

구성 실수로 인해 초기 노출이 발생합니다. 이미지 및 종속성 선택은 시간이 지남에 따라 노출이 어떻게 복합되는지를 결정합니다.

컨테이너보다 오래 지속되는 이미지 및 비밀 실수

컨테이너를 중지하면 컨테이너 내부의 구성 실수도 함께 중지됩니다. 취약성 또는 하드코드된 자격 증명이 포함된 이미지에서 다시 빌드하면 컨테이너에서 문제가 다시 시작됩니다. 이미지 수준 실수는 배포 간에 재설정되지 않습니다.

이미지를 가져오는 모든 환경, 이미지를 저장하는 모든 레지스트리, 실행하는 모든 팀 구성원으로 이미지를 가지고 이동합니다. 이러한 지속성은 이미지 및 비밀 관리를 구성과 별도로 감사할 가치가 있는 별도의 위험 범주로 만듭니다.

우리는 이 패턴을 자주 봅니다. 프로젝트 시작 시 신중하게 선택한 이미지는 그 이후로 다시 빌드되지 않았으며 처음에 표현된 보안 기준에서 천천히 표류합니다.

신뢰할 수 없거나 오래된 이미지 사용

공공등록부는 누구에게나 공개되어 있습니다. 컨테이너를 다시 시작해도 지속되는 계층 기록에 내장된 암호화 채굴기와 백도어를 운반하는 Docker Hub를 통해 악성 이미지가 배포되었습니다. 특히 비공식 또는 알려지지 않은 게시자의 이미지에 대해서는 문제를 가져오기 전에 확인하세요.

별도의 문제는 부실함입니다. 6개월 전에 가져온 공식 이미지에는 해당 패키지에 대해 공개된 각 CVE와 함께 패치되지 않은 Docker 취약점이 누적되어 있었습니다. 이미지가 깨지지 않았습니다. 더 이상 최신 상태가 아닙니다.

Sonatype의 2024년 소프트웨어 공급망 현황 보고서 취약한 구성 요소의 시간 중 95%가 소비되고, 수정된 버전이 이미 사용 가능하며, 애플리케이션 종속성의 80%가 1년 넘게 업그레이드되지 않은 상태로 남아 있다는 사실을 발견했습니다. 해당 패턴은 동일한 오픈 소스 패키지를 사용하므로 Docker 기본 이미지와도 관련이 있습니다.

"최신"에 의존하기보다는 검증된 게시자의 공식 이미지를 사용하고 특정 버전 태그를 고정하세요. 정기적인 재구축 흐름을 구축하여 이미지를 최신 상태로 유지하세요.

Dockerfiles 및 Compose 파일의 하드코딩 비밀

Dockerfile ENV 또는 ARG 명령어에 기록되거나, Compose 환경 블록에 하드코딩되거나, 빌드 인수로 전달되거나, 버전 제어를 위해 커밋된 .env 파일에 저장된 자격 증명은 컨테이너를 중지해도 사라지지 않습니다. 이미지 레이어 기록이나 소스 제어에 남아 있어 어느 누구라도 접근할 수 있습니다.

이는 개발 중에 눈에 띄는 문제를 일으키지 않기 때문에 가장 간과되는 Docker 보안 실수 중 하나입니다. ENV 명령어의 API 키가 올바르게 작동합니다. 또한 저장소에 있고 이미지에 구워져 이미지가 이동하는 모든 곳에 배포됩니다.

최신 Docker Compose는 자격 증명을 이미지에 굽지 않고 런타임에 마운트하는 기본 비밀 메커니즘을 지원합니다. Docker의 비밀 API와 외부 비밀 관리자는 동일한 원칙을 따릅니다. 이는 빌드 아티팩트 및 커밋된 파일에서 자격 증명을 완전히 유지하는 옵션입니다.

런타임 환경 변수는 하드코딩된 자격 증명보다 개선되었지만 여전히 Docker 검사 출력, 로그 및 크래시 덤프를 통해 노출됩니다. 이는 완성된 솔루션이 아니라 내장된 비밀에서 한 단계 더 발전한 것입니다.

컨테이너 이미지를 정기적으로 업데이트하지 않음

몇 달 동안 동일한 이미지를 실행하는 것은 일반적인 습관입니다. 새로운 취약점이 공개된 후 매일이 지나고 다시 빌드하기 전에 컨테이너에는 눈에 띄는 변화 없이 증가하는 노출 기간이 있습니다.

일관된 재구축 일정을 수립하세요. 가능한 경우 해당 프로세스를 자동화하고 현재 이미지에 대해 정기적으로 취약점 스캐너를 실행하십시오. 목표는 완벽함이 아니다. 패치 출시와 배포 사이의 시간이 단축되고 있습니다.

빠른 배포에서는 액세스 제어 및 모니터링의 우선 순위가 낮아질 수 있습니다. 또한 사건이 가장 오랫동안 감지되지 않는 범주이기도 합니다.

액세스 제어 및 가시성 격차

컨테이너가 견고한 구성과 현재 이미지로 실행된 후에는 두 가지 범주의 실패가 남습니다. 둘 다 본질적으로 보이지 않습니다. 누군가가 이를 사용하기 전까지는 취약한 액세스 제어 문제를 알아차리지 못할 것이며, 기록되지 않은 활동을 조사해야 할 때까지 모니터링 공백을 알아차리지 못할 것입니다.

같은 Red Hat 2024 연구 42%의 팀이 컨테이너 보안 및 관련 위협을 해결할 수 있는 충분한 역량이 부족하다는 사실을 발견했습니다.

모니터링 공백은 일반적으로 이전이 아닌 사고 조사 중에 표면화됩니다. 가시성이 우선순위가 되면 무언가를 방지하기보다는 이에 대응하는 경우가 많습니다.

취약한 인증 및 노출된 관리 대시보드

인증이 없는 공용 IP의 컨테이너 관리 대시보드에는 정교한 공격자가 필요하지 않습니다. 주소를 알아야 합니다. 이는 대부분의 팀이 인식하는 것보다 낮은 기준입니다.

자체 호스팅 모니터링 및 관리 도구는 일반적으로 모든 네트워크 인터페이스에서 액세스할 수 있는 웹 인터페이스와 함께 제공됩니다. 인증 없이 공용 IP에 남겨 두는 것은 관리자 패널을 잠금 해제 상태로 두는 것과 동일한 컨테이너입니다.

인증, 역방향 프록시 및 개인 네트워크 배치가 기준입니다. 액세스 제어는 활성화된 상태로 제공되는 것이 아니라 관리 인터페이스에 추가하는 구성 단계입니다.

동일한 원칙이 적용됩니다. Docker CLI 및 GUI 관리; 데몬에 대한 관리자 수준 액세스에는 인터페이스에 관계없이 동일한 위험이 따릅니다.

컨테이너가 수행하는 작업을 모니터링하지 않음

컨테이너가 손상되면 공격자의 활동으로 인해 프로세스 동작 변경, 비정상적인 네트워크 연결, 예상치 못한 파일 수정 등의 흔적이 생성됩니다. 로그 수집이 이루어지지 않으면 해당 추적은 조치를 취할 수 있는 형태로 존재하지 않습니다.

중앙 집중식 로그 수집, 컨테이너 감사 로깅 및 런타임 모니터링 도구는 비정상적인 활동이 결합되기 전에 감지할 수 있는 데이터를 제공합니다. 목표는 모든 라인을 분석하는 것이 아닙니다. 조사해야 할 때 데이터를 사용할 수 있습니다.

로그 파이프라인이나 경고 없이 프로덕션에서 자동으로 실행되는 컨테이너 설정은 유지 관리가 적습니다. 그들은 검사를 받지 않았습니다. 이는 두 가지 다른 작동 상태입니다.

인프라 환경도 중요한 이유

컨테이너 보안은 구성으로 시작되지만 구성은 인프라 위에서 실행됩니다. 잘못 구성된 네트워킹, 공유 리소스가 있거나 네트워크 수준 필터링이 없는 호스트는 그 위의 모든 컨테이너에 영향을 미치는 조건을 만듭니다. 컨테이너 설정을 올바르게 하는 것과 서버 구성을 올바르게 하는 것은 두 가지 별도 작업입니다.

많은 Docker 보안 격차는 컨테이너 자체가 상속하는 조건에 의해 증폭됩니다.

• 테넌트 간 하드웨어 격리가 없는 공유 테넌시 서버
• 패치되지 않은 상태로 실행되는 호스트 커널
• 네트워크 수준 필터링이 내장되지 않은 호스트

인프라 계층에 관계없이 적절한 컨테이너 강화가 중요하므로 위의 구성 단계가 필요하지 않습니다. 격리된 인프라에서 시작하면 문제의 한 단계가 제거됩니다.

Cloudzy에서는 설정에 필요한 사항에 따라 두 가지 경로를 제공합니다.

• 리눅스 VPS: Docker를 직접 배포하고 이 문서의 강화 단계를 적용할 수 있는 깨끗한 환경
• 포터테이너 VPS: Portainer가 사전 설치된 원클릭 옵션; 서버가 부팅되고 이미 대시보드에 있습니다.

두 옵션 모두 동일한 인프라에서 실행됩니다. KVM 가상화, 최대 5.7GHz 부스트 클럭의 AMD Ryzen 9 CPU, DDR5 메모리, NVMe SSD 스토리지, 최대 40Gbps 네트워크, BuyVM 필터링을 통한 무료 DDoS 보호, 전 세계 12개 위치에서 99.95% 가동 시간 SLA를 제공합니다.

VPS에서 Portainer를 실행하는 방법에 대해 자세히 알아보려면 관련 기사에서 다룹니다.

Docker 배포를 위한 실용적인 보안 체크리스트

위의 Docker 보안 실수는 대부분 한 번 이루어진 단일 구성 결정에서 발생하고 다시 검토되지 않습니다. 기존 설정에 대해 이 체크리스트를 실행하면 이러한 차이가 발견됩니다. 배포 가이드가 아닌 감사 역할을 합니다.

이러한 Docker 보안 모범 사례에서는 위에 설명된 가장 일반적인 구성 오류로부터 Docker 컨테이너를 보호하는 방법을 다룹니다.

빠른 참조: 9가지 실수 모두

이미 차이가 있을 가능성이 가장 높기 때문에 기존 설정에 대해 먼저 실행하는 것이 좋습니다.

루트가 아닌 사용자로 실행되는 컨테이너: Dockerfile에서 USER 지시어를 확인하세요. 존재하지 않는 경우 컨테이너는 루트로 실행됩니다.

로컬 호스트 또는 프록시로 제한되는 포트 바인딩: docker ps를 실행하고 포트 바인딩을 검토합니다. 0.0.0.0:PORT 항목은 업스트림 보안 그룹, 외부 방화벽 또는 DOCKER-USER 체인 규칙이 이를 차단하지 않는 호스트에서 공개적으로 접근할 수 있습니다.

사용 중인 사용자 정의 브리지 네트워크: Docker의 기본 브리지에 있는 컨테이너는 서로 자유롭게 연결할 수 있습니다. 동일한 사용자 정의 브리지에 있는 컨테이너는 계속해서 서로 통신할 수 있으므로 실제 격리를 위해 신뢰 경계를 기준으로 별도의 네트워크에 서비스를 분할합니다.

Docker 소켓이 컨테이너에 마운트되지 않았습니다. 파일 작성을 확인하고 인수를 실행하십시오. /var/run/docker.sock이 볼륨으로 나타나는 경우 해당 볼륨이 필수이고 의도적인 것인지 확인하세요.

고정된 버전이 있는 확인된 게시자의 기본 이미지: FROM ubuntu:latest는 지정되지 않은 잠재적으로 오래된 버전을 가져옵니다. 특정 릴리스에 고정합니다.

Dockerfiles, Compose 파일 또는 빌드 인수에는 비밀이 없습니다. 이미지 레이어 기록은 컨테이너 삭제 후에도 자격 증명을 유지합니다. Compose 비밀, Swarm 비밀, 빌드 비밀 마운트 또는 외부 비밀 관리자를 사용하세요. 런타임 환경 변수는 하드코딩된 값보다 좋지만 검사 출력 및 로그에는 계속 나타납니다.

이미지 재구축 일정이 정의됨: 오래된 이미지에는 취약점이 축적됩니다. 월간 재구축 케이던스는 대부분의 설정에서 노출 창을 관리 가능하게 유지합니다.

인증 뒤의 관리 인터페이스: 인증이 없는 공용 IP의 모든 대시보드는 공개 진입점입니다. 가능하다면 개인 네트워크 배치가 바람직합니다.

수집 중인 컨테이너 로그: 로그 파이프라인이 없으면 사고 감지는 눈에 보이는 시스템 영향에 따라 달라집니다. 이는 조치를 취해야 한다는 늦은 신호입니다.

결론

Docker의 기본 구성은 보안이 아닌 편의를 위해 구축되었습니다. 이 기사에서 다루는 대부분의 실수는 정교한 공격이 아니라 초기 배포 후 변경되지 않은 설정으로 거슬러 올라갑니다.

수정 사항은 대부분 USER 지시문, 포트 바인딩 변경, 사용자 정의 네트워크, 재구축 일정 등 일회성 구성 결정입니다. 대부분의 설정에는 새로운 도구가 필요하지 않습니다.

컨테이너 구성을 올바르게 설정하는 것이 첫 번째 작업입니다. 그것이 실행되는 인프라는 두 번째입니다. 둘 다 중요하며 어느 쪽도 다른 쪽을 대체할 수 없습니다.

FAQ