Cosign 이미지 서명 도입 — 도입 비용보다 *키 회전* 이 진짜 비싸다

Cosign 도입 자체는 *2주*. 키 회전 정책 정착에 *7개월*. 그 갭에서 만난 4가지 부서지는 가정.

백재민
백재민
CollabOps 창업자
Cosign 이미지 서명 도입 — 도입 비용보다 *키 회전* 이 진짜 비싸다

Cosign 도입 블로그 글 들이 다루는 부분 — 어떻게 서명 하나. 이 단계는 2주 만에 끝난다. 그 다음 7개월 동안 우리가 풀어야 했던 건 키 회전 — 거의 모든 가이드가 생략 한 부분.

이 글은 그 7 개월의 4가지 부서지는 가정 이다.

가정 1 — 키는 안전한 곳에 두면 회전이 필요 없을 줄

KMS 에 박은 키는 안 새는다고 가정. 따라서 회전 없이 영구 사용. 틀렸다.

키 회전이 필요한 이유:

  • KMS 자체 정책 (AWS KMS 의 자동 회전 옵션이 활성화되면 강제)
  • 키 사용자 변경 (퇴사한 사람이 키 사용 권한을 가졌으면 회전 필요)
  • 공식 권고 (NIST SP 800-57: 서명 키 수년 단위 회전)
  • 실제 누출 (KMS 자체는 안전해도 클라이언트 측 노출 가능)

가정 2 — 키 회전 = 새 키 발급 이라는 가정

자동화에서 키 회전 을 구현할 때, 보통 새 키 발급 + 새 키로 서명 으로 끝남. 틀렸다.

진짜 키 회전은 5 단계:

  1. 새 키 발급
  2. 새 키 공개 부분 배포 (검증자에게)
  3. 과도기 — 이전 키 + 새 키 둘 다 유효
  4. 새 키로만 서명 시작
  5. 이전 키 무효화 (취소·삭제)

3번 과도기 가 핵심. 이걸 빼면 회전 직후 모든 검증 실패.

가정 3 — 검증자가 즉시 갱신될 줄

새 키의 공개 부분을 검증 시스템 (admission controller, scanner) 에 배포하면 즉시 적용 될 줄. 틀렸다.

각 검증자의 키 캐시 TTL 이 다름. Kyverno 는 5분, Sigstore Policy Controller 는 다른 값. 즉시 적용 안 됨. 과도기최소 캐시 TTL 의 2배 는 되어야.

우리 사례 — 과도기를 15분 으로 잡았음. 한 검증자의 캐시 TTL 이 24시간 인 것을 몰랐음. 회전 후 24시간 동안 일부 환경에서 이미지 거부.

가정 4 — 회전 빈도가 자동 결정될 줄

회전 빈도는 자동 으로 결정 안 됨. 조직이 명시적으로 결정해야 함.

요인:

  • 법적 요구 (FIPS, 일부 규제 산업) — 연 1회 가 표준
  • 인사 변경 빈도 — 키 사용 권한자가 분기 1회 변경되면 분기 회전
  • KMS 청구 비용 — 회전 시 새 KMS 자원이 생김 (오래된 건 유지 — 아직 검증해야 하니까)
  • 사고 후 조치 — 의심 누출 시 즉시 회전

우리 결정 — 연 1회 + 사고 시 즉시. 이 결정 자체에 2개월의 정치.

7 개월의 시간 분배

작업                                    | 시간    | 비고
───────────────────────────────────────┼────────┼────────────────────
Cosign 도입 (서명 + 검증 기본)          | 2주    | 가이드 그대로
키 회전 정책 결정                        | 8주    | 정치적 비용 큼
회전 자동화 스크립트                     | 4주    | 5단계 모두
검증자 cache TTL 발굴 + 정렬            | 4주    | 검증자별 다름
첫 회전 시도 + 실패 + postmortem        | 4주    | 24시간 이미지 거부
두 번째 회전 시도 + 성공                 | 2주    | 
회전을 분기 routine 으로 정착           | 4주    | 
───────────────────────────────────────┼────────┼────────────────────
총                                       | 28주 = 7개월

Cosign 도입 자체는 7%. 나머지 93% 가 회전.

첫 회전 실패의 교훈

24시간 이미지 거부의 postmortem 결론 — 모든 검증자의 cache TTL 을 알고 있어야 한다. 검증자 추가 시점에 이걸 문서화 안 하면 다음 회전 때 다시 부서짐.

우리는 검증자 등록 절차cache TTL 명시 필드 를 추가. 새 검증자 등록 시 이 필드 없으면 등록 X.

누가 이 글을 읽으면 좋은가

지금 Cosign 도입을 검토 또는 서명만 도입한 모든 보안 / DevOps 리드. 서명 만 도입하고 회전 을 미룬 채로 6개월 이 지나면, 회전 시점에 위 4 가정 을 모두 한꺼번에 마주친다. 처음부터 회전을 함께 설계하는 게 정답.

태그#cosign#supply-chain#signing#security#devsecops