Docker 리드·아키텍트 보안 면접

첫째, Docker Content Trust(DCT)와 Notary를 활용한 이미지 서명 체계를 구축하고 Private Registry에 서명된 이미지만 허용하는 정책을 수립합니다. 둘째, Trivy, Clair, Anchore 등의 취약점 스캔 도구를 CI/CD 파이프라인에 통합하여 빌드 시점에 critical/high severity CVE가 있는 이미지는 배포를 차단하는 게이트를 설정합니다. 셋째, OPA(Open Policy Agent)나 Admission Controller를 통해 승인된 레지스트리와 베이스 이미지 목록만 사용하도록 정책을 강제하고, 기존 이미지는 단계적으로 화이트리스트 기반으로 마이그레이션합니다. 넷째, SBOM(Software Bill of Materials) 생성을 의무화하여 각 이미지의 구성 요소를 추적 가능하게 하고, 새로운 CVE 발표 시 영향 범위를 신속히 파악할 수 있는 체계를 구축합니다. 다섯째, 개발팀 교육과 함께 승인된 베이스 이미지 템플릿을 제공하고, 정기적인 이미지 재빌드 자동화를 통해 최신 보안 패치가 적용되도록 합니다. 마지막으로 Registry 접근 로그 모니터링과 이상 탐지 시스템을 구축하여 비정상적인 이미지 pull/push 활동을 실시간으로 감지합니다.

첫째, 즉시 조치로 이미지 레이어에 포함된 시크릿을 식별하기 위해 git-secrets, truffleHog 등으로 전체 이미지를 스캔하고, 발견된 시크릿은 즉시 로테이션하며 해당 이미지를 삭제합니다. 둘째, 단기 조치로 Kubernetes etcd 암호화를 활성화하고, RBAC를 재설계하여 네임스페이스별 시크릿 접근 권한을 최소 권한 원칙에 따라 분리합니다. 셋째, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault 등 전문 시크릿 관리 솔루션을 도입하여 중앙화된 시크릿 저장소를 구축하고, 동적 시크릿 생성 및 자동 로테이션 기능을 활용합니다. 넷째, 애플리케이션이 시크릿에 접근하는 방식을 Sidecar 패턴(Vault Agent, secrets-store-csi-driver)으로 전환하여 애플리케이션 코드 변경 없이 런타임에 시크릿을 주입하도록 합니다. 다섯째, BuildKit의 secret mount 기능이나 multi-stage build를 활용하여 빌드 시점에 필요한 시크릿이 최종 이미지 레이어에 남지 않도록 CI/CD 파이프라인을 개선합니다. 마지막으로 시크릿 접근 로그 감사 체계를 구축하고, 정기적인 시크릿 로테이션 정책과 만료 관리 자동화를 통해 지속적인 보안 태세를 유지합니다.

첫째, 컨테이너 런타임 보안 강화를 위해 gVisor나 Kata Containers 같은 샌드박스 런타임을 도입하여 커널 레벨 격리를 강화하고, 특히 신뢰할 수 없는 워크로드는 별도의 격리된 런타임에서 실행합니다. 둘째, Seccomp 프로파일과 AppArmor/SELinux 정책을 모든 컨테이너에 적용하여 시스템 콜을 화이트리스트 기반으로 제한하고, 불필요한 Linux capabilities(CAP_SYS_ADMIN, CAP_NET_RAW 등)를 제거합니다. 셋째, 네트워크 레벨에서 Service Mesh(Istio, Linkerd)를 도입하여 모든 컨테이너 간 통신을 mTLS로 암호화하고, 제로 트러스트 네트워크 정책을 통해 명시적으로 허용된 통신만 가능하도록 마이크로세그멘테이션을 구현합니다. 넷째, Falco나 Sysdig 같은 런타임 보안 모니터링 도구를 배포하여 비정상적인 시스템 콜, 파일 접근, 네트워크 활동을 실시간으로 탐지하고 자동 대응합니다. 다섯째, 각 테넌트 워크로드를 별도의 네임스페이스와 네트워크 격리 영역에 배치하고, NetworkPolicy를 통해 테넌트 간 트래픽을 완전히 차단합니다. 마지막으로 정기적인 침투 테스트와 컨테이너 탈출 시나리오 기반 레드팀 훈련을 통해 보안 태세를 지속적으로 검증합니다.