Cosign 이미지 서명 도입 — 도입 비용보다 *키 회전* 이 진짜 비싸다
Cosign 도입 자체는 *2주*. 키 회전 정책 정착에 *7개월*. 그 갭에서 만난 4가지 부서지는 가정.
Cosign 도입 블로그 글 들이 다루는 부분 — 어떻게 서명 하나. 이 단계는 2주 만에 끝난다. 그 다음 7개월 동안 우리가 풀어야 했던 건 키 회전 — 거의 모든 가이드가 생략 한 부분.
이 글은 그 7 개월의 4가지 부서지는 가정 이다.
가정 1 — 키는 안전한 곳에 두면 회전이 필요 없을 줄
KMS 에 박은 키는 안 새는다고 가정. 따라서 회전 없이 영구 사용. 틀렸다.
키 회전이 필요한 이유:
- KMS 자체 정책 (AWS KMS 의 자동 회전 옵션이 활성화되면 강제)
- 키 사용자 변경 (퇴사한 사람이 키 사용 권한을 가졌으면 회전 필요)
- 공식 권고 (NIST SP 800-57: 서명 키 수년 단위 회전)
- 실제 누출 (KMS 자체는 안전해도 클라이언트 측 노출 가능)
가정 2 — 키 회전 = 새 키 발급 이라는 가정
자동화에서 키 회전 을 구현할 때, 보통 새 키 발급 + 새 키로 서명 으로 끝남. 틀렸다.
진짜 키 회전은 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 서명 만 도입하고 키 회전 을 미룬 채 6개월 이 지나면, 회전 시점에 위 4 가정 을 전부 한꺼번에 마주치게 된다. 지금 Cosign 도입을 검토 중이거나 서명만 돌리고 있는 보안 / DevOps 리드에게 정답은 하나 — 처음부터 회전을 함께 설계하는 것.
비슷한 글
기획자가 코드를 배포하면, 장애는 누가 책임질까
AI로 제품 담당자가 직접 코드를 만들고 여러 에이전트가 동시에 작업하는 조직에서, 운영에 나가는 변경을 누가 무엇으로 확인해야 하는지. NIST SSDF, SLSA provenance, Google SRE 포스트모템 문화를 근거로 작성자와 분리된 검증·승인·복구의 역할 설계를 정리했다.
백재민
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백