컨테이너 이미지 서명은 빌드한 이미지에 암호학적 서명을 붙여, 배포 시점에 "이게 우리 파이프라인이 만든 그 이미지가 맞는지"를 검증하게 만드는 소프트웨어 공급망 보안 기법이다. Sigstore 프로젝트의 cosign이 사실상 표준 도구이고, 개인 키를 관리할 필요 없는 키리스(keyless) 서명이라는 방식으로 진입 장벽을 크게 낮췄다.
공급망 공격이 무서운 이유는, 코드에 손대지 않아도 레지스트리에 밀어 넣은 이미지 하나로 프로덕션이 뚫린다는 점이다. 태그는 언제든 덮어쓸 수 있고, latest는 어제의 latest가 아니다. 서명과 검증은 이 신뢰의 빈틈을 메운다.
키리스 서명이 바꾼 것
예전 서명 방식의 최대 골칫거리는 개인 키였다. 어디에 보관하고, 어떻게 로테이션하고, 유출되면 어쩌나. 키리스 서명은 이걸 우회한다. CI가 OIDC 신원(예: GitHub Actions의 워크플로 신원)으로 단기 인증서를 발급받아 그 순간에만 서명하고, 서명 기록은 공개 투명성 로그(Rekor)에 남는다. 장기 보관하는 비밀이 없다.
# CI(예: GitHub Actions)에서 키 없이 서명
# id-token: write 권한이 있으면 OIDC로 신원 증명이 됨
cosign sign --yes \
registry.example.com/checkout@sha256:abc123...
# 서명 검증 — "누가(신원) 어디서(워크플로) 서명했는가"까지 확인
cosign verify \
--certificate-identity-regexp="https://github.com/myorg/.+" \
--certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
registry.example.com/checkout@sha256:abc123...여기서 태그가 아니라 다이제스트(@sha256:...)로 서명하는 게 중요하다. 태그는 이동하지만 다이제스트는 이미지 내용 그 자체를 가리킨다. 태그에 서명하면 나중에 태그가 다른 이미지를 가리켜도 서명이 유효해 보이는 허점이 생긴다.
SBOM과 프로버넌스까지
서명은 시작일 뿐이다. 요즘은 세 가지를 함께 붙인다.
- 서명: 이 이미지가 위변조되지 않았다.
- SBOM(Software Bill of Materials): 이 이미지 안에 어떤 패키지·버전이 들어 있나. CVE가 터졌을 때 "우리 어디에 그 라이브러리가 있지?"를 즉시 답하게 해 준다.
- 프로버넌스(provenance, SLSA): 이 이미지가 어떤 소스·커밋·빌더로 만들어졌나. 빌드 과정의 족보다.
cosign attest로 SBOM이나 프로버넌스를 이미지에 첨부(attestation)할 수 있다. 서명과 마찬가지로 검증 시점에 확인한다.
배포 시점 강제 — admission으로 막기
서명만 해 두고 검증을 강제하지 않으면 절반짜리다. 진짜 방어선은 클러스터가 서명 안 된 이미지의 실행을 거부하게 만드는 것이다. 쿠버네티스라면 정책 컨트롤러(예: Kyverno)로 admission 단계에서 검사한다.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: { name: require-signed-images }
spec:
validationFailureAction: Enforce
rules:
- name: verify-checkout
match: { any: [{ resources: { kinds: [Pod] } }] }
verifyImages:
- imageReferences: ["registry.example.com/checkout*"]
attestors:
- entries:
- keyless:
issuer: "https://token.actions.githubusercontent.com"
subject: "https://github.com/myorg/*"| 첨부물 | 답하는 질문 |
|---|---|
| 서명(signature) | 위변조되지 않았나? |
| SBOM | 무엇이 들어 있나? |
| 프로버넌스 | 어떻게 만들어졌나? |
현실적인 시작점
솔직히 처음부터 Enforce로 걸면 배포가 다 막혀서 원성을 산다. 나는 Audit 모드로 먼저 켜서 "서명 없는 이미지가 지금 얼마나 굴러다니는지"를 며칠 관찰한다. 목록이 정리되고 CI에 서명 단계가 다 붙은 걸 확인한 뒤에야 Enforce로 조인다. 순서를 지키면 사고 없이 넘어간다.
자주 묻는 질문
키리스 서명은 정말 키가 하나도 없나요?
장기 보관하는 개인 키가 없다는 뜻입니다. 서명 순간에 단기 인증서용 키가 만들어졌다가 폐기되고, 신원 증명은 OIDC 토큰으로 대체합니다. 유출되면 큰일 나는 "보관된 비밀"이 사라지는 게 핵심 장점입니다.
SBOM만 만들면 공급망 보안이 되나요?
SBOM은 "무엇이 들었나"의 목록일 뿐, 그 자체로 위변조를 막지는 못합니다. 서명으로 무결성을 보장하고, SBOM으로 구성 요소를 파악하고, admission으로 실행을 통제하는 세 층이 함께 있어야 실효가 있습니다.
Rekor 투명성 로그는 왜 필요한가요?
키리스 서명은 인증서가 단기라 이미 만료됐을 수 있는데, Rekor에 "그 인증서가 유효하던 시점에 서명이 이뤄졌다"는 기록이 남아 사후 검증이 가능합니다. 공개 추가 전용 로그라 서명 이력을 은밀히 지울 수 없다는 점도 중요합니다.
사설 레지스트리에서도 되나요?
됩니다. cosign은 서명을 OCI 아티팩트로 레지스트리에 함께 저장하므로, 이미지를 담을 수 있는 레지스트리라면 서명도 담깁니다. 폐쇄망이라면 Rekor·Fulcio를 사내에 자체 호스팅하는 구성도 가능합니다.
댓글 0