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 리드에게 정답은 하나 — 처음부터 회전을 함께 설계하는 것.
비슷한 글
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백
이클립스는 그대로 쓰셔도 됩니다 — IDE 연동과 ITSM 연동에 대한 답
개발툴로 이클립스를 쓰는데 어떻게 연동되냐는 질문과, ITSM 과 연동되냐는 질문은 거의 항상 같이 나온다. 표준 Git 프로토콜이라는 답의 의미, 그리고 ITSM 연동 요구의 진짜 본질이 증적 체인이라는 이야기.
백재민