Tailscale 상태 파일 암호화, 기본 설정에서 비활성화됨

 (tailscale.com)
1P by GN⁺ | ★ favorite | 댓글 2개
  • Tailscale v1.92.5 버전에서 Linux와 Windows 클라이언트의 상태 파일 암호화(state file encryption) 및 하드웨어 인증 키 기능이 기본적으로 비활성화됨
  • TPM 장치가 재설정되거나 교체된 경우에도 클라이언트가 정상적으로 시작되며, 하드웨어 인증 키 로드 실패가 실행을 막지 않음
  • Tailscale 컨테이너 이미지에서는 하드웨어 인증 키가 더 이상 Kubernetes 상태 Secrets에 추가되지 않아, 컨테이너를 다른 노드로 이동 가능
  • Tailscale Kubernetes Operator는 인증서 갱신 시 ARI 주문 방식을 기본적으로 사용하지 않으며, 하드웨어 인증 키를 Secrets에 저장하지 않음
  • 이번 변경은 Tailscale의 보안 기능 구성 방식을 단순화하고, 다양한 환경에서의 배포 유연성을 높이는 업데이트임

Tailscale v1.92.5 업데이트

  • Linux 및 Windows 클라이언트

    • Secure node state storage 관련 기능 중 상태 파일 암호화와 하드웨어 인증 키가 기본적으로 비활성화됨
    • TPM(Trusted Platform Module) 장치가 재설정되거나 교체되어도 클라이언트 시작이 차단되지 않음

  • Tailscale 컨테이너 이미지

    • 새 버전이 Docker Hub 및 GitHub Packages에서 제공
    • 하드웨어 인증 키가 Kubernetes 상태 Secrets에 추가되지 않아, Tailscale 컨테이너를 다른 Kubernetes 노드로 옮길 수 있음

  • Tailscale Kubernetes Operator

    • 새 버전이 설치 가이드에 따라 배포 가능
    • 인증서 갱신 시 ARI 주문 방식을 기본적으로 사용하지 않아, ACME 계정 키가 재생성될 때 발생할 수 있는 갱신 실패를 방지
    • 하드웨어 인증 키가 Kubernetes 상태 Secrets에 추가되지 않아, Operator를 다른 노드로 이동 가능

  • Tailscale tsrecorder

    • Docker Hub에서 새 버전 제공
    • 이번 릴리스는 라이브러리 업데이트만 포함, 기능 변경 없음

2026년 1월 5일 — Workload Identity Federation API

2025년 12월 23일 — GitHub Action v4.1.1

  • Tailscale GitHub Action이 macOS 기반 GitHub Runner에서 캐시 저장 및 검색 시 올바른 아키텍처를 사용하도록 수정됨

함께 보면 좋은 글 β

joyfui   [-]

엇 얼마전에 이거 관련해서 유틸 배포해주신 분 글을 본 거 같은데...

답변달기
GN⁺   [-]
Hacker News 의견들
  • 나는 Tailscale에서 node state encryption 기능을 처음 구현했던 엔지니어임 (@awly on Github). 이번에 1.92.5 버전에서 기본값을 꺼두기로 결정했음
    다른 댓글에서 추측한 대로, 이 기능은 지원 부담이 너무 큼. 원래는 TPM이 리셋되거나 교체되면 무조건 변조로 간주하고 클라이언트가 실행을 거부하도록 설계했음. 하지만 실제로는 비악의적인 이유로 TPM이 불안정한 경우가 많았음
    예시로 이슈 17654, 이슈 18288, 이슈 18302 등이 있음.
    TPM은 조직이 장비를 잘 통제할 수 있을 때는 훌륭한 도구지만, Tailscale처럼 다양한 환경의 장비를 지원해야 하는 서비스에는 너무 복잡함. 그래서 지금은 보안에 민감한 사용자나 관리자가 직접 활성화하도록 두었음. changelog에 이런 맥락을 더 담았어야 했는데, 그 부분은 미안하게 생각함
    • 링크된 이슈들을 읽어보니 놀라웠음. TPM 문제가 오래된 장비나 특수한 환경에서만 생길 줄 알았는데, Dell XPS나 여러 VM에서도 발생했음.
      나는 대부분의 Tailscale 인스턴스를 VM과 컨테이너에서 돌리고 있는데, 실제로 TPM 암호화가 적용된 건 내 주요 PC, iPhone, 그리고 리눅스 서버의 호스트뿐이었음. VM이나 컨테이너에서는 전혀 작동하지 않았고, 노트북은 너무 오래돼서 지원이 안 된 듯함
    • 정책이 매우 합리적이라고 생각함. 설명해줘서 고맙게 생각함
    • 이슈 17654에서 어떤 사용자가 “TS_ENCRYPT_STATE=false” 설정으로도 해결되지 않았다고 했는데, 이후 버전 1.92.1에서는 문제가 사라졌다고 함.
      이런 경우는 실제로 state encryption 문제였는지, 아니면 다른 원인이었는지 좀 더 설명해줄 수 있는지 궁금함
    • 나도 TPM을 신뢰했었는데, BIOS 업데이트 한 번으로 TPM이 완전히 초기화되어버림. 그 이후로는 TPM에 의존하지 않기로 했음
    • 이렇게 솔직하게 설명해줘서 고맙게 생각함. changelog에 이런 배경이 조금이라도 들어가면 좋겠음.
      상황이 복잡하다면 짧은 블로그 포스트로 따로 정리해주는 것도 환영함
  • 이 기능은 애초에 기본 활성화되면 안 됐음. 관리자가 TPM을 쓰겠다고 명시적으로 선택해야 함
    changelog에도 나와 있듯이, TPM이 리셋되거나 교체되면 하드웨어 인증키를 불러오지 못해 클라이언트가 시작되지 않는 문제가 있었음.
    많은 배포 환경에서는 이 기능이 꼭 필요하지만, Tailscale이 워낙 다양한 OS와 장비에서 돌아가다 보니 예측 불가능한 충돌이 너무 많았음
    • TPM을 암호화 용도로 써보려 할 때마다 결국 복구용 비밀번호나 백업키가 필요해짐. 그런데 그건 TPM의 목적 자체를 무의미하게 만듦.
      작은 실수 하나로 사용자의 키가 완전히 사라질 수도 있어서, 실제로는 쓰기 어렵다고 느낌
    • Windows는 기본적으로 TPM을 사용하지 않나? 그렇다면 수백만 명의 Windows 사용자가 문제를 겪었어야 함.
      그래서 이건 약간 과도한 대응처럼 보임. 일부 TPM 예외 케이스 때문에 전체 기능을 꺼버린 건 아쉬움.
      중간 단계(예: 선택적 활성화)가 있었으면 좋았을 것 같음
    • TPM이 리셋되거나 교체되면 차단하는 게 오히려 물리적 공격 방어 측면에서는 올바른 동작 아닌가 하는 의문이 듦
  • 이 PR에 비활성화 이유가 설명되어 있음.
    TPM 품질의 편차가 너무 커서 다양한 문제를 일으켰다고 함
  • changelog를 보면 기본 활성화로 인한 문제 때문인 듯함 (내부 정보는 없음).
    다만 이 문제가 해결되면 다시 기본 활성화할 계획이 있는지 궁금함.
    나는 Tailscale 팀을 신뢰하지만, 감시 우려가 커지는 요즘 같은 시기에 이런 변경이 정부 요구 때문은 아닌지 명확한 이유를 듣고 싶음
    • 문제의 원인은 Tailscale이 아니라 TPM 하드웨어 자체의 불안정성 때문이라고 봄.
      그래서 이 기능은 통제된 환경에서만 선택적으로 쓰는 게 맞다고 생각함
  • 오래된 하드웨어의 NixOS 머신에서 Tailscale이 계속 크래시 나서 이유를 몰랐는데, 이번 변경 덕분에 원인을 알게 됨. TPM 암호화 때문이었음
  • 아마도 지원 요청이 너무 많아서 비활성화한 것 같다고 추측함
  • 지난 한 달 동안 Tailscale이 계속 고장 나 있었는데, 오늘 나온 패치가 그 문제를 해결했음.
    원인은 BIOS 업데이트였고, 그 후 Tailscale이 “Starting” 상태에서 멈춘 채 아무 오류도 표시하지 않았음
  • 나는 USB에 설치한 Linux를 데스크탑과 노트북에서 번갈아 부팅하는데, 어느 날 갑자기 Tailscale이 작동하지 않았음.
    내 경우만 특이한 줄 알았는데, TPM 기반 암호화가 다른 이유로도 실패한다는 걸 알게 됨
  • Linux에서는 /etc/default/tailscaled에 FLAGS="--encrypt-state"를 추가하면 되는 듯함.
    로그에 "migrated ... to TPM-sealed format" 메시지가 보여서 잘 작동하는 것 같음
  • 이런 이유로 대중 시장에서는 1%라도 깨지는 기능을 기본으로 넣을 수 없음.
    결국 가장 낮은 공통 분모에 맞춰야 하고, 완벽한 보안보다는 안정성 우선으로 갈 수밖에 없음.
    내가 Tailscale을 운영했다면 “TPM 고장난 사람은 스스로 고쳐라, 우리는 기본적으로 보안을 유지하겠다”고 했을지도 모르겠음.
    하지만 Avery가 결정을 내리는 이유가 있음을 이해함
답변달기