목차
컨테이너 이미지의 공급망 보안은 이제 선택이 아닌 필수입니다. 악의적인 혹은 의도치 않은 이미지 변경을 막고 프로덕션 환경에 신뢰할 수 있는 이미지만 배포하려면 어떻게 해야 할까요?
핵심은 빌드 → 푸시 → 서명 → 검증으로 이어지는 파이프라인을 표준화하고, 키 관리와 신뢰 정책을 코드로 관리하는 것입니다. 이 글에서는 컨테이너 이미지 서명 및 검증 파이프라인을 구축하는 구체적인 방법과 핵심 고려사항을 단계별로 정리했습니다.
1. 서명 도구 선택: Notation vs. Cosign vs. AWS Signer
가장 먼저 조직의 기술 스택과 운영 모델에 맞는 서명 도구를 선택해야 합니다. 각 도구는 고유한 장단점을 가집니다.
- Notation: CNCF 프로젝트로, ACR(Azure Container Registry) 및 AKV(Azure Key Vault)와의 통합이 뛰어납니다. 기업용 인증서(CA) 기반 모델에 익숙한 팀에게 적합하며, ACR Tasks나 CI/CD 파이프라인과 연동해 빌드 후 서명을 자동화할 수 있습니다.
- Cosign: Sigstore 프로젝트의 일부로, 키가 필요 없는(Keyless) OIDC 방식과 투명성 로그(Rekor)를 통해 빠른 도입과 자동화에 강점이 있습니다.
cosign verify --key <KMS/URL> <image>와 같이 간단한 명령어로 검증할 수 있습니다. - AWS Signer: AWS 환경에 최적화된 관리형 서비스입니다. CodePipeline, CodeBuild, ECR과 긴밀하게 연계하여 서명 및 검증 파이프라인을 구축하는 모범 사례를 제공합니다. Kyverno 같은 정책 엔진과 결합하면 배포 전 검증을 쉽게 강제할 수 있습니다.
도구별 특성 비교표
| 도구 | 키 관리 | 주요 통합 환경 (예시) | 검증 정책/강제 지점 | 운영 비용 | 예외 처리 |
|---|---|---|---|---|---|
| Notation | AKV/CA 기반 | ACR, Azure DevOps 파이프라인 | 레지스트리, Admission Controller | 중 | 워크플로 승인 |
| Cosign | 키리스(OIDC), KMS, 파일 키 | 다양한 CI/CD 및 레지스트리 | Admission Controller, OPA, 레지스트리 | 낮~중 | 이미지 주석/레이블 |
| AWS Signer | KMS 연계 (관리형 서비스) | CodePipeline, CodeBuild, ECR | 레지스트리, 배포 단계 | 중 | 리소스 태그/브랜치 |
2. 키 보관 전략: KMS vs. Key Vault
서명에 사용할 키를 어떻게 안전하게 보관하고 관리할지는 매우 중요합니다.
- 키리스(Keyless) vs. 장기 키: 먼저 조직의 PKI 정책에 따라 키리스 방식을 사용할지, 아니면 장기 키를 사용할지 결정해야 합니다. 키리스는 OIDC를 통해 단기 인증서로 서명하므로 키 분실이나 유출 위험이 낮고 키 회전이 용이합니다. 하지만 신원 공급자(IdP)와 투명성 로그에 대한 의존도가 높습니다.
- HSM 기반 관리: AWS KMS나 Azure Key Vault 같은 관리형 서비스를 사용하면 HSM(하드웨어 보안 모듈)을 통해 키를 강력하게 보호하고 모든 접근에 대한 감사 추적을 제공할 수 있습니다. Azure는 Notation AKV 플러그인을 통해 키 보관, 서명, 타임스탬프 작업을 일관되게 운영할 수 있도록 지원합니다.
3. CI/CD 파이프라인 통합: 빌드 → 푸시 → 서명 → 검증
이미지 서명과 검증은 CI/CD 파이프라인의 핵심 단계로 통합되어야 합니다.
- Build: 컨테이너 이미지를 빌드하고, SBOM(소프트웨어 자재 명세서)과 같은 서명 대상 메타데이터를 함께 생성합니다.
- Push: 빌드된 이미지를 컨테이너 레지스트리에 푸시합니다.
- Sign: Notation 또는 Cosign을 사용하여 레지스트리에 푸시된 이미지에 서명합니다. (키리스, AKV, KMS 등 선택한 방식 사용)
- Verify: 이미지를 프로덕션 환경에 배포하기 직전, 서명을 검증하는 단계를 추가합니다. 검증 실패 시 파이프라인은 즉시 중단되어야 합니다.
- AWS 환경: CodePipeline/CodeBuild와 ECR, AWS Signer를 연동하여 파이프라인 내에서 서명과 검증을 자동화합니다.
- Azure 환경: Azure DevOps 파이프라인이나 ACR Tasks에 Notation 서명 단계를 삽입하고 Azure Key Vault를 연동하여 키를 관리합니다.
구축 체크리스트
- 서명 키 생성 및 신원 확인 방식 결정 (키리스 vs. KMS/AKV)
- 레지스트리에 신뢰 정책 정의 (서명되지 않은 이미지 Pull 금지)
- CI/CD 파이프라인에 "Sign" 단계 추가 및 실패 처리 로직 구현
- 배포 파이프라인에 "Verify" 단계 필수화 (Admission Controller/Webhook 활용)
- 예외 케이스에 대한 승인 절차 및 로그, 근거 보존 방안 마련
- 주기적인 키 회전 및 타임스탬프 유효성 검증 계획 수립
4. 레지스트리 정책으로 서명 강제하기
가장 효과적인 통제 지점 중 하나는 컨테이너 레지스트리 자체입니다. 레지스트리 차원에서 "서명된 이미지만 Pull 허용" 정책을 설정하면, 신뢰할 수 없는 이미지가 클러스터로 유입되는 것을 원천 차단할 수 있습니다.
- 스코프 최소화: 정책 적용 시, 특정 리포지토리나 태그 패턴에만 적용하여 예외를 최소화하는 것이 좋습니다.
- 클라우드 네이티브 기능 활용: AWS ECR과 Signer, Azure ACR과 Notation은 각각 서명 강제 정책에 대한 모범 사례와 튜토리얼을 제공하므로, 이를 조직 표준으로 삼아 점진적으로 확산하는 전략을 추천합니다.
- 관련 글: 예외 규칙·오탐 절차 비교
정책 강제 지점별 장단점
| 구간 | 장점 | 단점 |
|---|---|---|
| 레지스트리 정책 | 단일 제어 지점(Single Point of Control)으로 운영이 단순함 | 런타임 컨텍스트를 고려한 세밀한 정책 적용이 어려움 |
| Admission Controller | 클러스터의 네임스페이스 등 다양한 컨텍스트 기반의 정밀 제어 가능 | 운영 복잡도가 높고, 클러스터 성능에 영향을 줄 수 있음 |
| CI 단계 | 개발자에게 빠른 피드백을 제공하여 비용 절감 효과 | 런타임에 외부에서 유입되는 이미지를 차단하기는 어려움 |
5. 예외 및 제외 조건 승인 절차
모든 이미지에 서명을 강제하기 어려운 경우가 있습니다. (예: 서드파티 이미지, 베타 테스트, 만료된 인증서 등) 이런 불가피한 예외는 명확한 절차에 따라 관리해야 합니다.
- 요청 기반 승인: 예외 요청 시 ‘기간, 대상 범위(스코프), 사유’를 명시한 요청서를 통해 공식적인 승인을 받도록 합니다.
- 기술적 통제: 예외는
exception/*과 같은 특정 태그 접두어나 전용 네임스페이스로 한정하고, 반드시 만료일을 설정하여 장기적인 보안 허점으로 남지 않도록 관리합니다. - 관련 글: RBAC 최소권한·검증 권한 절차, 정책 as code·예외 관리
6. 검증 실패 시 자동 롤백 및 차단
서명 검증에 실패했다면 배포는 즉시 차단되어야 하며, 가능하다면 안정적인 이전 버전으로 자동 롤백되어야 합니다.
- GitOps 연동: Argo CD와 같은 GitOps 도구를 사용하면, 배포 컨트롤러가 서명 검증 실패를 오류로 인식하고 마지막으로 서명이 확인된 리비전으로 자동 롤백하도록 구성할 수 있습니다.
- Admission Webhook: 쿠버네티스 Admission Webhook은 서명, 서명 체인, 타임스탬프가 유효하지 않을 경우 API 요청을
deny로 응답하여 배포를 원천 차단합니다. Cosign, OPA, Kyverno 정책을 조합하여 구현하는 것을 권장합니다. - 관련 글: 오류 원인 분류·핸들링
7. 감사 로그 및 서명 체인 보존
"누가, 언제, 무엇을, 어떻게 서명했는가"를 증명하는 것은 보안 감사의 핵심입니다.
- 증명(Attestation) 데이터 보존: Cosign의 투명성 로그나 Notation의 서명 번들(bundle)을 안전한 곳에 아카이빙해야 합니다. 또한 서명 시점의 SBOM, 빌드 파이프라인 실행 로그 등 증빙 자료를 함께 보존하여 서명의 신뢰도를 높일 수 있습니다.
- OCI 아티팩트 서명: AWS Signer는 컨테이너 이미지뿐만 아니라 SBOM, Helm 차트 같은 다양한 OCI 아티팩트를 서명하고 검증하여 전체 공급망의 신뢰 체인을 강화할 수 있습니다.
8. 운영 비용 및 성능 고려사항
서명 및 검증 파이프라인은 비용과 성능에 영향을 미칠 수 있습니다.
- 성능 최적화: 이미지 Pull, Pod 생성 시 발생하는 검증 레이턴시를 관리하기 위해 캐시 전략(예: 검증된 베이스 이미지 미러링), 병렬 검증, 정책 적용 스코프 축소 등을 고려해야 합니다.
- 비용 관리: 주요 비용 항목은 ‘서명 건수 × 타임스탬프 호출 × KMS/AKV API 호출’입니다. 자주 변경되지 않는 베이스 이미지나 캐시 이미지는 재검증 주기를 길게 설정하여 비용을 최적화할 수 있습니다.
간단한 성능 지표:
릴리즈 차단율(%) = (검증 실패 빌드 수 ÷ 전체 릴리즈 시도 수) × 100
자주 묻는 질문 (FAQ)
Q1. 여러 클라우드 및 온프레미스 레지스트리 간에 서명 호환이 가능한가요?
A. 네, OCI 표준 아티팩트와 Notation/Cosign 형식을 따르면 이식성이 높습니다. 다만, 레지스트리별로 정책 플러그인이나 세부 기능에 차이가 있을 수 있으므로, Admission Controller나 OPA를 통해 상위 레벨에서 일관된 정책을 적용하는 것이 좋습니다.
Q2. 서명 키를 회전(rotate)할 때 이미 배포된 서비스에 영향이 없나요?
A. 영향을 최소화하려면, 새 키로 서명한 이미지를 배포함과 동시에 이전 키를 일정 기간 동안 유효하게 유지하는 정책이 필요합니다. 레지스트리의 신뢰 루트(Trust Root)와 Admission 정책에 새 키와 이전 키를 동시에 반영하는 작업이 필수적입니다.
Q3. 캐시된 이미지나 공용 베이스 이미지는 어떻게 처리해야 하나요?
A. "검증된 베이스 이미지"를 위한 별도의 내부 레지스트리(또는 리포지토리)를 운영하는 것을 권장합니다. 이곳에 저장된 이미지는 정기적으로 재서명 및 재검증(특히 타임스탬프 만료 전)하는 프로세스를 자동화해야 합니다. AWS/ACR의 미러링 기능을 활용하면 네트워크 성능과 안정성도 확보할 수 있습니다.
Q4. 서명 검증 실패 시 자동 롤백은 어떤 순서로 이루어지나요?
A. 일반적인 순서는 다음과 같습니다.
- CI/CD 파이프라인의 배포 단계에서 서명 검증 실패.
- Admission Controller가 배포 요청을 거부(deny).
- GitOps 컨트롤러가 배포 실패를 감지하고 마지막으로 "서명이 확인된" 릴리즈 버전으로 자동 롤백.
- 실패 이벤트에 대한 감사 로그를 기록하고 담당자에게 알림을 보냅니다.
Q5. 관리자가 정책을 우회하여 미서명 이미지를 배포하는 것을 어떻게 탐지하나요?
A. 레지스트리의 이미지 Pull 로그와 쿠버네티스 클러스터의 Admission 거부 로그를 상호 대조하여 정책 위반 시도를 탐지할 수 있습니다. 또한, Kyverno나 OPA 같은 정책 엔진을 사용하여 클러스터 내에서 실행 중인 미서명 이미지를 주기적으로 탐지하는 감사 규칙을 운영해야 합니다.
면책 조항: 본문에 언급된 클라우드 서비스의 정책 및 요금은 변경될 수 있으며, 실제 적용 사례는 조직의 환경에 따라 상이할 수 있습니다. 항상 최신 공식 문서를 확인하시기 바랍니다.
