보안이 최고라며 TPM 잠금 걸었다가, 프로덕션 노드 교체하고 4시간 동안 접속 끊긴 사연

솔직히 말해서, 오늘 아침 RSS 리더를 훑다가 등골이 서늘했습니다. Tailscale v1.92.5 릴리스 노트를 보는데, 딱 한 문장이 제 3년 전 트라우마를 끄집어냈거든요.

"Linux 및 Windows에서 State file 암호화와 hardware attestation keys가 기본적으로 더 이상 활성화되지 않습니다."

이 한 줄이 무슨 의미인지 아십니까? 보안이 중요하지 않다는 말이 아닙니다. "보안 타령하다가 서비스 가용성(Availability) 말아먹는 짓 좀 그만하자"는, 피 섞인 항복 선언처럼 보였습니다. 저도 그랬거든요. 국비 학원 출신 주제에 어디서 주워들은 건 있어서 "보안은 타협하는 게 아니다"라며 객기를 부렸던 적이 있습니다.

그때 저는 쿠버네티스(Kubernetes) 환경에서 내부망 접근 제어를 설계하고 있었습니다. "제로 트러스트(Zero Trust)"라는 말이 얼마나 멋져 보이던지. 그래서 Tailscale을 도입하면서 문서에 있는 모든 보안 옵션을 다 켰습니다. 그중 하나가 바로 'State file 암호화'와 'Hardware attestation'이었습니다.

이론은 완벽했습니다. 디스크에 저장되는 상태 파일(State file)을 암호화하고, 그 암호화 키를 서버의 물리적 TPM(Trusted Platform Module) 칩에 묶어버리는 겁니다. 이렇게 하면 누군가 하드디스크를 떼어가도, 혹은 컨테이너 이미지를 복제해가도 인증 정보를 훔쳐 쓸 수 없으니까요. "이게 바로 금융권 수준 보안이지" 하면서 혼자 뿌듯해했습니다.

재앙은 금요일 밤 11시에 터졌습니다.

클라우드 제공사(CSP)에서 노후 장비 교체를 위해 저희 EKS 노드 중 하나를 강제로 재부팅 시켰습니다. 쿠버네티스는 당연히 해당 노드에 있던 파드(Pod)들을 다른 노드로 스케줄링했고요. 이론적으로는 아무 문제가 없어야 했습니다. 그게 쿠버네티스를 쓰는 이유니까요.

그런데 Tailscale을 통해 관리하던 백오피스와 모니터링 대시보드가 싹 다 먹통이 됐습니다. SSH 접속도 안 됐습니다. 왜냐고요?

새로운 노드로 옮겨간 Tailscale 컨테이너가 시작을 못 하고 CrashLoopBackOff 상태에 빠져 있었기 때문입니다. 로그를 까보니 가관이더군요. 이전 노드의 TPM 키로 암호화된 상태 파일을, 새로운 노드(물리적으로 다른 TPM을 가진 장비)에서 복호화하려고 시도하다가 실패한 겁니다.

하드웨어 증명(Hardware attestation)이 뭡니까. "이 하드웨어가 아니면 실행하지 마라"는 뜻입니다. 그런데 클라우드 네이티브 환경은 "하드웨어는 언제든 교체될 수 있다"는 걸 전제로 합니다. 저는 이 두 가지 상충하는 개념을 억지로 묶어놓고, 운영 서버를 시한폭탄으로 만들어 놨던 겁니다.

그날 새벽 3시까지 복구하면서 뼈저리게 느꼈습니다. 비즈니스가 멈추면 그 완벽한 보안이 무슨 소용입니까?

이번 Tailscale v1.92.5 업데이트 내역을 보면, 개발팀도 똑같은 고민을 했다는 게 느껴집니다. 변경 로그에 적힌 내용을 그대로 읊어보자면 이렇습니다. "TPM 장치가 재설정되거나 교체될 때 클라이언트가 시작되지 못하는 문제가 더 이상 발생하지 않습니다."

특히 컨테이너 환경에서는 더 드라마틱합니다. 이제 Hardware attestation keys가 Kubernetes state Secrets에 추가되지 않는다고 합니다. 이게 무슨 말이냐면, 이제야 비로소 Tailscale 컨테이너가 배포되는 노드를 자유롭게 변경할 수 있게 됐다는 뜻입니다. 보안 레벨을 아주 조금 낮추는 대신, '생존'을 택한 겁니다.

문서를 꼼꼼히 읽어보니, 리눅스(Linux)와 윈도우(Windows) 모두 이 기능이 기본값에서 '비활성화(Off)'로 변경되었습니다. 이제 막 인프라를 구축하는 주니어 분들이라면 이 변경 사항이 주는 함의를 깊게 생각해보셨으면 좋겠습니다.

물론, 보안은 중요합니다. 하지만 우리는 SI 프로젝트 파견 나가서 공무원들이 쓰는 PC에 보안 모듈 깔다가 블루스크린 띄워본 경험이 있지 않습니까? 그때 욕을 먹는 건 보안 정책을 만든 사람이 아니라, 현장에 있는 개발자입니다.

이번 업데이트에는 또 다른 흥미로운 점들이 있습니다.

Tailscale Kubernetes Operator 업데이트를 보면, 이제 운영자가 인증서 갱신 실패를 피하기 위해 ACME 계정 키 재생성 로직을 개선했습니다. 이것도 결국 '가용성' 이야기입니다. 인증서 갱신 안 돼서 서비스 멈추는 것만큼 허무한 장애도 없거든요.

그리고 API 쪽에서는 Workload identity federation을 지원한다고 합니다. AWS나 Google Cloud 같은 외부 자격 증명(Identity)을 그대로 가져다 쓸 수 있다는 건데, 이건 보안을 강화하면서도 편의성을 해치지 않는 좋은 방향입니다. tailscale up 명령어를 칠 때 --client-id와 --id-token 플래그를 써서 인증할 수 있다는 건, CI/CD 파이프라인에서 써먹기 아주 좋다는 뜻이죠.

하지만 오늘의 핵심은 역시 '기본값의 변화'입니다.

개발자는 종종 "Best Practice"라는 말에 속습니다. 구글이 하니까, 넷플릭스가 하니까, 보안 가이드에 나와 있으니까 무조건 적용해야 한다고 믿습니다. 하지만 여러분의 서비스가 넷플릭스가 아니고, 여러분의 팀이 구글 보안팀 규모가 아니라면, 그 Best Practice는 독이 될 수 있습니다.

코드는 더러워도 비즈니스는 돌아가야 합니다. 인프라도 마찬가지입니다. 조금 덜 안전해 보여도, 서버가 죽었을 때 1분 안에 다시 살아나는 구조가 훨씬 더 가치 있습니다.

이번 Tailscale의 롤백 결정을 보면서 묘한 위로를 받습니다. "그래, 너희도 겪어보니 운영이 먼저지?"라고 묻고 싶네요.

혹시 지금도 Hardware Attestation 같은 고급 기능을 무턱대고 켜놓은 분들이 계신다면, 다시 한번 점검해보시길 바랍니다. 그 서버, 내일 당장 클라우드 벤더사가 하드웨어 교체한다고 공지 띄우면 무사할 수 있습니까?

우리는 화려한 아키텍처를 자랑하기 위해 일하는 게 아닙니다. 오늘 밤도 무사히 서비스를 살려놓기 위해 일하는 겁니다. 그걸 잊지 마세요.