Docker 시니어 보안 면접
새 면접Q. 프로덕션 환경에서 Docker 컨테이너에 민감한 정보(API 키, DB 비밀번호, 인증서)를 안전하게 전달하는 방법을 설명해주세요. 환경변수, Docker Secrets, 외부 시크릿 관리 도구(Vault, AWS Secrets Manager)의 보안 특성과 트레이드오프를 비교하고, 시크릿이 컨테이너 이미지 레이어나 로그에 노출되는 것을 방지하는 전략을 설명해주세요.
시크릿이 저장되는 위치와 전달 메커니즘, 그리고 런타임에만 접근 가능하도록 하는 방법을 고려하세요.
환경변수는 간편하지만 docker inspect, 프로세스 목록, 로그에 노출될 위험이 있어 프로덕션에 부적합합니다. Docker Swarm의 Secrets는 encrypted Raft log에 저장되고 tmpfs로 마운트되어 디스크에 기록되지 않으며, 필요한 컨테이너에만 전달됩니다. Kubernetes 환경에서는 Secret 리소스를 사용하되 etcd 암호화를 활성화해야 합니다. 더 강력한 보안이 필요하면 HashiCorp Vault나 AWS Secrets Manager를 사용해 동적 시크릿 생성과 자동 로테이션을 구현합니다. Dockerfile에서 ARG로 시크릿을 전달하면 이미지 레이어에 영구 저장되므로 BuildKit의 --secret 마운트를 사용해야 합니다. 시크릿 접근은 최소 권한 원칙을 적용하고, 감사 로그를 통해 접근 이력을 추적해야 합니다.
- • 환경변수는 docker inspect와 로그에 노출되어 프로덕션에 부적합
- • Docker Secrets는 tmpfs 마운트로 디스크에 기록되지 않음
- • Vault 같은 외부 도구로 동적 시크릿 생성과 자동 로테이션 구현
- • BuildKit --secret 마운트로 빌드 시 시크릿이 레이어에 남지 않도록 방지
마이크로서비스 환경에서 데이터베이스 비밀번호나 API 키를 안전하게 관리하고 자동으로 로테이션할 때 사용됩니다.
시크릿 로테이션 시 무중단으로 컨테이너에 새로운 시크릿을 적용하는 방법은 무엇인가요?
Q. Docker 이미지의 보안 취약점을 스캔하고 관리하는 전략을 설명해주세요. Trivy, Clair, Snyk 같은 스캐너의 동작 원리와 CVE 데이터베이스 활용 방법, 그리고 CI/CD 파이프라인에 통합하여 취약점이 있는 이미지의 배포를 차단하는 정책 기반 승인 프로세스를 설계하는 방법을 설명해주세요. 특히 false positive 처리와 취약점 우선순위 결정 기준을 포함해주세요.
이미지 레이어별 패키지 분석, CVE 심각도 평가, 그리고 배포 전 자동 차단 메커니즘을 고려하세요.
Trivy, Clair 같은 스캐너는 이미지 레이어를 분석해 설치된 패키지 목록을 추출하고 CVE 데이터베이스와 매칭하여 알려진 취약점을 탐지합니다. CI/CD 파이프라인에서 이미지 빌드 직후 스캔을 실행하고, CRITICAL이나 HIGH 등급 취약점이 발견되면 배포를 차단하는 게이트를 설정합니다. Admission Controller(Kubernetes)나 Registry Webhook을 통해 런타임에도 취약한 이미지 실행을 방지할 수 있습니다. False positive는 CVE의 실제 영향 범위를 분석하고, 해당 패키지가 실제 사용되는지 확인한 후 예외 목록으로 관리합니다. 우선순위는 CVSS 점수, 공격 가능성(exploit 존재 여부), 영향 범위(인터넷 노출 여부)를 종합적으로 고려합니다. 정기적인 이미지 재스캔과 베이스 이미지 업데이트 자동화로 지속적인 보안 유지가 필요합니다.
- • 이미지 레이어 분석으로 패키지 추출 후 CVE 데이터베이스 매칭
- • CI/CD 파이프라인에서 심각도 기반 배포 차단 게이트 설정
- • Admission Controller로 런타임 취약 이미지 실행 방지
- • CVSS 점수, exploit 존재, 영향 범위로 우선순위 결정
프로덕션 배포 전 보안 취약점을 자동으로 탐지하고 위험한 이미지의 배포를 사전에 차단할 때 사용됩니다.
베이스 이미지 업데이트 시 애플리케이션 호환성 문제를 최소화하면서 보안 패치를 적용하는 전략은 무엇인가요?
Q. Docker 컨테이너의 런타임 보안을 강화하기 위한 Seccomp, AppArmor, SELinux 프로파일의 동작 원리와 적용 방법을 설명해주세요. 각 보안 메커니즘이 방어하는 공격 유형과 기본 프로파일의 한계, 그리고 애플리케이션별 커스텀 프로파일을 작성하는 전략을 설명해주세요. 특히 컨테이너 탈출(container escape) 공격을 방어하는 방법을 포함해주세요.
시스템 콜 필터링, 강제 접근 제어, 그리고 최소 권한 원칙 적용 방법을 생각해보세요.
Seccomp은 컨테이너가 호출할 수 있는 시스템 콜을 화이트리스트 방식으로 제한하여 커널 취약점 공격을 차단합니다. Docker의 기본 Seccomp 프로파일은 약 300개 시스템 콜을 허용하지만, 애플리케이션별로 실제 필요한 시스템 콜만 허용하는 커스텀 프로파일 작성이 권장됩니다. AppArmor와 SELinux는 MAC(Mandatory Access Control)로 파일, 네트워크, 프로세스 접근을 세밀하게 제어합니다. 컨테이너 탈출 방어를 위해서는 privileged 모드 금지, CAP_SYS_ADMIN 같은 위험한 capability 제거, read-only 루트 파일시스템 사용이 필요합니다. 커스텀 프로파일은 strace로 애플리케이션의 시스템 콜을 분석한 후 최소 권한만 허용하도록 작성하며, 테스트 환경에서 충분히 검증 후 적용합니다. Falco 같은 런타임 보안 도구로 비정상 행위를 실시간 탐지하는 것도 중요합니다.
- • Seccomp으로 시스템 콜을 화이트리스트 방식으로 제한
- • AppArmor/SELinux로 파일과 네트워크 접근 제어
- • privileged 모드 금지와 위험한 capability 제거로 컨테이너 탈출 방지
- • strace 분석으로 최소 권한 커스텀 프로파일 작성
멀티테넌트 환경에서 악의적인 컨테이너가 호스트 시스템에 접근하거나 다른 컨테이너를 공격하는 것을 방지할 때 사용됩니다.
컨테이너에서 CAP_NET_ADMIN capability가 필요한 경우 보안 위험을 최소화하는 방법은 무엇인가요?
Q. Docker 컨테이너 간 네트워크 트래픽을 암호화하고 상호 인증(mutual TLS)을 구현하는 방법을 설명해주세요. overlay 네트워크의 기본 암호화 기능과 한계, 그리고 서비스 메시(Istio, Linkerd)를 도입하여 zero-trust 네트워크 보안을 구현하는 전략을 설명해주세요. 특히 인증서 관리와 키 로테이션 자동화 방법을 포함해주세요.
네트워크 레벨 암호화와 애플리케이션 레벨 mTLS의 차이, 그리고 인증서 자동 발급 메커니즘을 고려하세요.
Docker overlay 네트워크는 --opt encrypted 옵션으로 IPsec을 통한 VXLAN 터널 암호화를 지원하지만, 컨테이너 간 상호 인증은 제공하지 않습니다. 서비스 메시는 사이드카 프록시를 통해 모든 트래픽을 자동으로 mTLS로 암호화하고, 서비스 ID 기반 인증과 세밀한 접근 제어를 제공합니다. Istio는 Citadel(현재 istiod)이 자동으로 인증서를 발급하고 짧은 TTL로 로테이션하여 키 유출 위험을 최소화합니다. zero-trust 모델에서는 네트워크 위치가 아닌 서비스 ID로 인증하며, 기본적으로 모든 통신을 거부하고 명시적으로 허용된 경로만 열어줍니다. cert-manager나 SPIFFE/SPIRE를 사용하면 인증서 라이프사이클을 자동화할 수 있습니다. 네트워크 정책(NetworkPolicy)과 결합하여 레이어 3/4 수준의 트래픽 제어도 함께 적용해야 합니다.
- • overlay 네트워크의 IPsec 암호화는 상호 인증 미제공
- • 서비스 메시로 사이드카 프록시 기반 자동 mTLS 구현
- • 짧은 TTL 인증서 자동 발급과 로테이션으로 키 유출 위험 최소화
- • 서비스 ID 기반 zero-trust 모델 적용
마이크로서비스 간 통신을 암호화하고 서비스 간 인증을 자동화하여 내부 네트워크 공격을 방어할 때 사용됩니다.
서비스 메시 도입 시 사이드카 프록시가 성능에 미치는 영향을 최소화하는 방법은 무엇인가요?
Q. 금융권이나 의료 분야처럼 강력한 컴플라이언스 요구사항이 있는 환경에서 Docker 컨테이너의 보안 감사 로그를 수집하고 분석하는 아키텍처를 설계해주세요. Docker API 호출, 컨테이너 생성/삭제, 이미지 pull/push, exec 명령 실행 등의 이벤트를 중앙에서 수집하고, 비정상 행위를 탐지하며, 규정 준수를 입증하는 방법을 설명해주세요. 특히 auditd, syslog, SIEM 통합 전략을 포함해주세요.
Docker 데몬 감사, 컨테이너 런타임 이벤트 추적, 그리고 변경 불가능한 감사 로그 저장을 고려하세요.
Docker 데몬의 모든 API 호출을 감사하려면 --log-level=debug와 함께 auditd를 설정하여 Docker 소켓(/var/run/docker.sock) 접근을 추적합니다. Linux audit 시스템으로 컨테이너 생성, exec 실행, 볼륨 마운트 같은 민감한 작업을 기록하고, ausearch로 분석합니다. 컨테이너 로그는 fluentd나 Logstash로 수집하여 Elasticsearch나 Splunk 같은 SIEM에 전송하며, 변조 방지를 위해 write-once 스토리지나 블록체인 기반 로그 저장소를 사용합니다. Falco는 런타임에 비정상적인 시스템 콜이나 파일 접근을 실시간 탐지하여 알림을 발생시킵니다. 컴플라이언스 입증을 위해서는 CIS Docker Benchmark 자동 스캔 결과, 취약점 스캔 이력, 접근 제어 정책 변경 이력을 시계열로 보관해야 합니다. 감사 로그는 최소 1년 이상 보관하며, 무결성 검증을 위한 체크섬을 함께 저장합니다.
- • auditd로 Docker 소켓 접근과 API 호출 추적
- • Falco로 런타임 비정상 행위 실시간 탐지
- • 변조 방지를 위한 write-once 스토리지나 SIEM 통합
- • CIS Benchmark 스캔과 취약점 이력을 시계열로 보관하여 컴플라이언스 입증
금융권이나 의료 분야에서 규제 준수를 입증하고 보안 사고 발생 시 포렌식 분석을 수행할 때 사용됩니다.
컨테이너 내부에서 발생한 보안 이벤트(예: 무단 파일 접근)를 호스트 레벨 감사 로그와 연관 분석하는 방법은 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!