나는 500줄의 cert-manager 구성을 50줄짜리 블루프린트로 교체했다

Source: Dev.to

새벽 3시 인증서 만료 위기

이런 상황을 겪어본 적 있나요? 폰이 PagerDuty 알림으로 가득 찹니다. 프로덕션 API가 다운됩니다. 코드가 나빠서가 아니라. DDoS 공격 때문이 아니라. 내부 서비스 인증서가 만료됐기 때문입니다.

아이러니하게도, cert‑manager를 이용한 “자동화”된 인증서 관리, 90일 회전, 모니터링, 런북이 있더라도 이런 일이 발생합니다.

이 위기는 너무 자주 반복됩니다.

내 경험: 6시간 복구 과정

• 긴급 인증서 갱신 – 45분
• 새 인증서를 적용하기 위해 파드 재시작 – 30분
• 근본 원인 분석 – 2시간
• 사후 보고서 작성 – 1시간
• “다시는 이런 일이 일어나지 않게” 런북 업데이트 – 2시간

3주 뒤, 다른 서비스. 같은 문제. 다른 인증서.

무엇을 배웠나요? 인증서 발급을 자동화한다고 해서 인증서 문제 자체가 사라지는 것은 아닙니다.

진짜 질문은 “인증서를 더 빨리 회전시키는 방법은?”이 아니라 “내부 동서 트래픽에 왜 인증서를 사용하고 있는가?” 입니다.

실제 “자동화된” 인증서 관리가 어떻게 보이는지

이전: cert‑manager

150 + 줄의 Certificate YAML

• Issuer 구성
• CertificateRequest 관리
• Secret 회전 스크립트
• 만료 모니터링 알림
• 긴급 갱신을 위한 Runbook

≈ 200 줄의 구성
≈ 30 %의 플랫폼 팀 시간 PKI 관리에 사용

이후: Lane7 Blueprint

# This is the entire deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-pod-1
spec:
  # ... standard Kubernetes deployment
  # Workload Security Proxy (WoSP) sidecar handles all networking, identity, and encryption

50 줄 전체. 10 분 안에 배포. 자격 증명은 Service A와 Service B(두 서비스 간) 간의 모든 통신 세션마다 신원‑신뢰 검증과 함께 회전합니다.

인증서 없음. PKI 없음. 새벽 3시 알림도 없음.

자동화된 PKI의 거짓 보안 담요

내가 “인증서 자동화”라고 생각했던 것:

• ✅ 90일마다 자동 갱신
• ✅ 파드에 자동 배포
• ✅ 만료 모니터링
• ✅ 수동 개입 전혀 없음

제로 트러스트처럼 들리나요?

틀렸습니다. 이것은 단지 “제로 터치” 발급일 뿐입니다.

자동화가 해결하지 못하는 문제들

1. The “Secret Zero” Problem – 첫 번째 비밀(Secret Zero)을 어떻게 안전하게 전달하나요? 인증서를 가져오는 첫 비밀을 전달하기 위해… 또 다른 비밀로 신뢰를 부트스트랩합니다. 끝없이 이어지는 거북이 이야기와 같습니다.
2. Certificate Authority = Single Point of Failure – 해당 CA가 침해되거나, 잘못 구성되었거나, 버그가 있으면 전체 보안 모델이 무너집니다.
3. Every cert rotation is an entirely new identity – 인증서가 교체될 때마다 애플리케이션은 신뢰된 상호작용 이력을 잃게 됩니다. 마치 90 일마다 사진, 주소, 서명이 다른 새로운 운전면허증을 받는 것과 같습니다.
4. Handshake Overhead – 각 연결마다 인증서 검증, 체인 확인, 폐기 여부 확인(OCSP/CRL), 키 교환 협상이 필요해 지연 시간과 CPU 부하가 내부 서비스 호출마다 증가합니다.
5. Static Identity Window – 90‑일 교체 주기라도 인증서는 디스크에 90 일 동안 남아 있습니다. 공격자가 첫 날에 인증서를 탈취하면 89 일 동안 사용할 수 있습니다.
6. Expiry Anxiety – 자동화가 아무리 뛰어나도 항상 다음과 같은 두려움이 존재합니다:
   • 교체 스크립트가 실패하면 어떻게 할까?
   • 웹훅이 타임아웃되면 어떻게 할까?
   • 모니터링 알림을 놓치면 어떻게 할까?

실현

나는 “자동화된 PKI”가 실제로 제로 트러스트가 아니라 단지 더 빠른 레거시 보안일 뿐이라는 것을 깨달았다. PKI는 제3자에 의해 검증된 루트 도메인에 대해 잘 작동한다. CSR을 제출하는 워크로드에 대한 검증은 이루어지지 않는다. 관심사는 신뢰가 아니라 빠른 TLS 연결을 위한 PKI이다.

신뢰 체인은 워크로드 자체가 아니라 인증 기관(Certificate Authority)에서 끝났다.

디스크에 저장된 파일에 의존하지 않고 서비스의 신원을 확인할 수 있는 방법이 필요했다.