# Tailscale 상태 파일 암호화, 기본 설정에서 비활성화됨 > Clean Markdown view of GeekNews topic #25666. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25666](https://news.hada.io/topic?id=25666) - GeekNews Markdown: [https://news.hada.io/topic/25666.md](https://news.hada.io/topic/25666.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-09T02:32:58+09:00 - Updated: 2026-01-09T02:32:58+09:00 - Original source: [tailscale.com](https://tailscale.com/changelog) - Points: 1 - Comments: 2 ## Topic Body - **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](https://tailscale.com/kb/1596/secure-node-state-storage) 관련 기능 중 **상태 파일 암호화**와 **하드웨어 인증 키**가 기본적으로 비활성화됨 - TPM(Trusted Platform Module) 장치가 재설정되거나 교체되어도 클라이언트 시작이 차단되지 않음 - **Tailscale 컨테이너 이미지** - 새 버전이 [Docker Hub](https://hub.docker.com/r/tailscale/tailscale) 및 [GitHub Packages](https://github.com/tailscale/tailscale/pkgs/container/tailscale)에서 제공 - 하드웨어 인증 키가 Kubernetes 상태 `Secrets`에 추가되지 않아, Tailscale 컨테이너를 다른 Kubernetes 노드로 옮길 수 있음 - **Tailscale Kubernetes Operator** - 새 버전이 [설치 가이드](https://tailscale.com/kb/1236/kubernetes-operator#installation)에 따라 배포 가능 - 인증서 갱신 시 **ARI 주문 방식**을 기본적으로 사용하지 않아, ACME 계정 키가 재생성될 때 발생할 수 있는 갱신 실패를 방지 - 하드웨어 인증 키가 Kubernetes 상태 `Secrets`에 추가되지 않아, Operator를 다른 노드로 이동 가능 - **Tailscale tsrecorder** - [Docker Hub](https://hub.docker.com/r/tailscale/tsrecorder/tags)에서 새 버전 제공 - 이번 릴리스는 **라이브러리 업데이트만 포함**, 기능 변경 없음 ### 2026년 1월 5일 — Workload Identity Federation API - [Tailscale API](https://tailscale.com/kb/1101/api)가 **페더레이션 ID(federated identities)** 생성, 조회, 수정, 삭제 기능을 지원 - [`tailscale-client-go-v2`](https://github.com/tailscale/tailscale-client-go-v2) 및 [Tailscale Terraform provider](https://tailscale.com/kb/1210/terraform-provider)에서도 동일한 기능을 구성 가능 ### 2025년 12월 23일 — GitHub Action v4.1.1 - [Tailscale GitHub Action](https://tailscale.com/kb/1276/tailscale-github-action)이 macOS 기반 GitHub Runner에서 캐시 저장 및 검색 시 올바른 아키텍처를 사용하도록 수정됨 ## Comments ### Comment 48942 - Author: joyfui - Created: 2026-01-09T13:16:11+09:00 - Points: 1 엇 얼마전에 이거 관련해서 유틸 배포해주신 분 글을 본 거 같은데... ### Comment 48914 - Author: neo - Created: 2026-01-09T02:32:58+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46531925) - 나는 Tailscale에서 **node state encryption** 기능을 처음 구현했던 엔지니어임 (@awly on Github). 이번에 1.92.5 버전에서 기본값을 꺼두기로 결정했음 다른 댓글에서 추측한 대로, 이 기능은 **지원 부담이 너무 큼**. 원래는 TPM이 리셋되거나 교체되면 무조건 변조로 간주하고 클라이언트가 실행을 거부하도록 설계했음. 하지만 실제로는 비악의적인 이유로 TPM이 불안정한 경우가 많았음 예시로 [이슈 17654](https://github.com/tailscale/tailscale/issues/17654), [이슈 18288](https://github.com/tailscale/tailscale/issues/18288), [이슈 18302](https://github.com/tailscale/tailscale/issues/18302) 등이 있음. TPM은 조직이 장비를 잘 통제할 수 있을 때는 훌륭한 도구지만, Tailscale처럼 **다양한 환경의 장비**를 지원해야 하는 서비스에는 너무 복잡함. 그래서 지금은 보안에 민감한 사용자나 관리자가 직접 활성화하도록 두었음. changelog에 이런 맥락을 더 담았어야 했는데, 그 부분은 미안하게 생각함 - 링크된 이슈들을 읽어보니 놀라웠음. TPM 문제가 오래된 장비나 특수한 환경에서만 생길 줄 알았는데, Dell XPS나 여러 VM에서도 발생했음. 나는 대부분의 Tailscale 인스턴스를 **VM과 컨테이너**에서 돌리고 있는데, 실제로 TPM 암호화가 적용된 건 내 주요 PC, iPhone, 그리고 리눅스 서버의 호스트뿐이었음. VM이나 컨테이너에서는 전혀 작동하지 않았고, 노트북은 너무 오래돼서 지원이 안 된 듯함 - 정책이 매우 합리적이라고 생각함. 설명해줘서 고맙게 생각함 - [이슈 17654](https://github.com/tailscale/tailscale/issues/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](https://github.com/tailscale/tailscale/pull/18336)에 비활성화 이유가 설명되어 있음. 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가 결정을 내리는 이유가 있음을 이해함