服務定位

Teleport 的核心定位是 infrastructure access plane、不是 IdP、不是 secret store、也不是 network mesh。它的責任是 把 admin / engineer 對 production 資源的 session 通通走可治理的入口、每個 session 有 identity-bound short-lived cert、有 audit log、有 錄影、有 MFA gate。比較對象：

• 跟 Okta / Azure AD 等 IdP 比、Teleport 不取代 SSO、而是 把 SSO identity 帶到 infrastructure layer — Okta 給 user identity + group、Teleport 把這個 identity 翻譯成 SSH cert / DB cert / K8s cert
• 跟傳統 bastion + SSH key 比、Teleport 把 long-lived SSH key 換成 short-lived cert（預設 TTL 數小時、過期自動失效）、把 看不到的 session 換成 全程錄影 + searchable audit log
• 跟 HashiCorp Boundary 比、Teleport 走 protocol-aware proxy（懂 SSH / PostgreSQL / Kubernetes API 協議、可以 decode keystroke 跟 query）、Boundary 走 generic TCP proxy（協議無感、不能錄 keystroke 但部署更輕）
• 跟 Tailscale SSH 比、Tailscale 是 network mesh 加 SSH、適合小團隊 flat network；Teleport 是 PAM + 多協議 + 跨環境 audit、適合需要 SOC handoff 的環境
• 跟 Cloudflare Access 比、Cloudflare Access 是 application-layer ZTNA（內部 web app / API 用）、Teleport 是 infrastructure-layer ZTNA（SSH / DB / K8s 用）、兩者互補

關鍵張力：PAM 的覆蓋完整度 ↔ operator 摩擦。Teleport 開越多（per-session MFA、Access Request 要 approval、Device Trust 強制企業裝置）、helpdesk SE 那種「拿到密碼直接進 prod」的 blast radius 越小、但 on-call engineer 在凌晨三點修事故時的摩擦也越大。要根據 資源敏感度分層 設定、不是一刀切。

本章目標

讀完本頁、讀者能判斷：

1. Teleport 在 access stack 中承擔哪一段（infrastructure session）、哪些不屬於它（user identity 屬 Okta、long-lived service secret 屬 Vault、application access 可用 Cloudflare Access）
2. Cluster / Proxy / Auth Service / Node 拓樸的部署選擇（Cloud SaaS vs Self-hosted、Trusted Cluster 跨環境）
3. Roles + Access Requests + Per-session MFA + Session Recording 四件套的工程化設定（誰能 approve、TTL 多長、錄影存哪）
4. 何時用 Teleport、何時走 Boundary / Tailscale SSH / Cloudflare Access 的取捨

最短判讀路徑

判斷 Teleport deployment 是否健康、最少看四件事：

• 是否還有 long-lived credential 旁路：production host 是否仍接受 ~/.ssh/authorized_keys 的長期 key、DB 是否仍有 shared admin password、K8s kubeconfig 是否還在 engineer laptop 永存 — Teleport 收編失敗的最大訊號是 存在 bypass Teleport 的捷徑
• Per-session MFA 是否對 sensitive resource 強制：prod SSH / prod DB / payment system 進 session 時是否每次都 re-MFA、不是「早上登入一次後 8 小時都通行」、role 設定有沒有 require_session_mfa: true
• Access Request 的 standing privilege 是否收零：日常 role 是否只有 read-only、所有 write / admin operation 是否走 Access Request + approver gate + TTL、approver 是否 SOC / SRE on-call 而非任意 lead
• Session Recording 是否真的可回查：SSH / K8s / DB session 錄影是否落地 S3 / GCS、是否可在 audit log 透過 user / time / resource 三軸搜尋並回放、recording retention 是否符合合規（金融通常 7 年）

四件事任一缺失、就回到 7.2 身分與授權邊界 補設定。最容易踩的是第三點 — Teleport 裝了但日常 role 仍給 standing admin、Access Request 變裝飾、helpdesk SE 場景的 mitigation 等於沒上。

日常操作與決策形狀

Cluster + Proxy + Auth Service 拓樸：Teleport cluster 由三個 first-class component 組成 — Auth Service（CA、簽 cert、存 audit log、policy decision point）、Proxy（user 連線入口、做 protocol translation、把 SSH / DB / K8s request 轉到 Node）、Node（被保護的資源、裝 Teleport agent 或走 agentless 模式）。Cloud（SaaS）把 Auth + Proxy 託管、客戶只管 Node；Self-hosted 三層都自管、適合需要 data residency / FedRAMP 的環境。

多協議 Resource Access：Teleport 是 protocol-aware proxy、不是 generic TCP tunnel — SSH Access 懂 OpenSSH、Database Access 懂 PostgreSQL / MySQL / MongoDB / Snowflake / Redis wire protocol、Kubernetes Access 懂 K8s API + RBAC impersonation、Desktop Access 懂 RDP、Application Access 懂 HTTP（包 AWS / GCP console 跟內部 web app）。協議感知的價值是 可以錄 keystroke / query / 滑鼠移動、可以做 per-query approval（DB Access 可設「DROP TABLE 要 approver」）、generic proxy 做不到。

Roles + RBAC：Teleport role 是 YAML 定義的 RBAC policy、控制 誰可以連哪些 resource、用什麼 OS user、執行什麼指令、session TTL 多長、要不要 per-session MFA。Role 跟 Okta group 透過 SAML / OIDC attribute mapping 綁定 — Okta group=sre-prod 自動拿到 Teleport role=prod-ssh-readonly、不用 Teleport 端維護 user list。

Access Requests（JIT approval）：standing privilege 收零的核心機制 — engineer 平常只有 read-only role、需要 write / admin 時透過 CLI / web UI 開 Access Request、指定 role + reason + TTL、approver 在 Slack / web 收到通知後 approve / deny、approve 後該 user 拿到該 role TTL（例如 4 小時）、過期自動 revoke。對應 MGM 2023 的 mitigation — 即使 helpdesk SE 拿到 user 密碼、該 user 也沒有 standing admin 可用、要進 prod 必須額外開 Access Request + approver 看到 reason 異常會 deny。

Per-session MFA：高敏 session 強制每次連線都 re-MFA、不是登入一次後 session TTL 內都通行。role 設 require_session_mfa: true、user tsh ssh prod-db-01 時會跳 Yubikey / WebAuthn 提示、過了才連得進去。對應 Uber 2022 MFA Fatigue 的 lesson — 即使 attacker 用 push fatigue 拿到 IdP session、要進 prod infrastructure 還會撞到第二道 MFA。

Session Recording + Audit：所有 SSH / K8s / DB / Desktop session 全程錄影、SSH 錄 keystroke + output、DB 錄 SQL query、K8s 錄 API call、Desktop 錄畫面。錄影預設存 Auth Service local disk、production 應該設 sync mode 即時寫 S3 / GCS、不要等 session 結束才上傳（attacker 結束前 wipe）。Audit log 走結構化 JSON、可 export 到 Splunk / Elastic、是 SOC 的 first-class signal。

Trusted Cluster 跨環境 federation：dev / staging / prod 各自跑 Teleport cluster、用 Trusted Cluster 建立信任關係、user 從 root cluster 一次 login 就能 tsh ssh --cluster=prod node-01、不用每個環境各 login。設計重點是 root cluster 是 SSO + 政策中心、leaf cluster 是各環境本地控制、leaf 出事不會把 root identity 拖下水。

跟 Okta / GitHub OIDC SSO 整合：Teleport 不做 user identity、authentication 全部委派給 IdP — Okta 設 SAML app、Teleport 設 SAML connector、user tsh login 跳 Okta 認證後拿 Teleport short-lived cert。GitHub Actions 也可以用 OIDC token 換 Teleport cert（給 CI 用、見下方 Machine ID）、不用埋 GitHub Actions secret。

核心取捨表

選 Teleport 的核心訴求：多協議 infrastructure session + session recording + JIT + per-session MFA 是 SOC 必要證據 + 跨環境 federation（dev / staging / prod / partner）+ 願意承擔 cluster 維運成本（self-hosted）或 SaaS 訂閱。純小團隊 flat network 走 Tailscale 更輕、純內部 web app 走 Cloudflare Access 更便宜、純 Vault-driven workflow 走 Boundary 整合更順。

進階主題

Machine ID — service-to-service short-lived cert：CI / 內部 worker / cron job 也走 Teleport 拿 short-lived cert、不用埋長期 SSH key 或 DB password。Machine ID agent（tbot）跑在 CI runner、用 IAM role / GitHub OIDC token / Kubernetes service account 證明自己身份、Teleport 簽 short-lived SSH cert / DB cert（TTL 通常 1 小時）。對應 SPIRE 的 workload identity 概念、Teleport Machine ID 是 SPIRE 在 infrastructure access surface 的對等實作。

Device Trust — 裝置驗證：除了 user identity + MFA、Teleport Enterprise 還可以強制 只有企業 enrolled 裝置可以連 prod。裝置透過 TPM / Secure Enclave 註冊 hardware-bound key、Teleport login 時驗證裝置 cert。對應 BYOD 風險 — 即使 attacker 拿到 user credential + MFA token、沒有企業裝置就連不進 prod。

Moderated Session + Session Live View：高敏 session 設定 需要第二人在線 moderate、SOC analyst 即時看 keystroke、可以 kill session。對應金融 / 政府的「四眼原則」合規要求。Live View 也可以給 SOC 在 incident 進行中即時看 attacker 操作（如果 attacker 不知道被監聽）。

FedRAMP / HIPAA / PCI compliance：Teleport Enterprise 有 FedRAMP Moderate authorization、Self-hosted 模式可部署 air-gapped 環境、audit log 滿足 HIPAA / PCI 的 access logging 要求。Cloud 版本走 SOC 2 Type II、FedRAMP 版本走 GovCloud 部署。

跟 Vault / SPIRE 的職責切分：Vault 管 service-to-service secret（DB password、API key、PKI CA）、SPIRE 管 workload identity（SVID、跨服務 mTLS）、Teleport 管 人類 admin session + service short-lived cert（透過 Machine ID）。三者互補不重疊 — Vault 不該直接給 engineer 拿 SSH key、SPIRE 不該管 helpdesk admin 怎麼進 prod、Teleport 不該變成長期 API key 倉庫。

排錯與失敗快速判讀

• 裝了 Teleport 但 engineer 還在用直接 SSH key：production host 沒收掉 authorized_keys、long-lived key 旁路存在 — host onboarding 流程強制走 Teleport Node enrollment、CI 跑 sshd_config audit 抓 AuthorizedKeysFile
• Access Request 變裝飾、approver 秒按：approver 是同團隊 lead 沒看 reason、TTL 設 24 小時等於 standing — approver 改 SOC on-call / cross-team、TTL 預設 1-4 小時、high-impact role 強制兩人 approve
• Per-session MFA 開了但 user 抱怨太煩：所有 role 一刀切要 MFA — 分層：dev / staging role 只要登入 MFA、prod role 才 per-session MFA、payment / PII DB 加 moderated session
• Session recording 沒存到 S3、attacker 結束前 wipe：用 default async mode、recording 留在 Auth Service local — 改 sync mode 即時寫 S3、S3 開 object lock 防刪除
• Trusted Cluster leaf 出事拖累 root：leaf cluster admin 也有 root cluster 權限 — leaf 用獨立 role mapping、leaf admin 不繼承 root identity、leaf 出事只影響該環境
• Cloud SaaS 跨區 latency 高：team 在亞太但 Teleport Cloud 在 us-east — 選 Teleport Cloud 地區 / 改 Self-hosted 部署在自家最近 region
• Machine ID cert TTL 短導致 CI 中途失效：long-running job > cert TTL — 在 job 內定期 tbot renew、或拉長 TTL 但收緊 IAM role binding

何時改走其他服務

不在本頁內的主題

• Teleport role YAML 完整 reference、predicate language 進階用法
• Teleport Cloud vs Self-hosted 的 SLA / pricing 細節
• Teleport Connect（桌面 client app）的具體操作流程
• Air-gapped 部署的 license server 跟 update workflow
• 各協議的 wire protocol 解析（PostgreSQL / MySQL session 怎麼被 decode）

案例回寫

Teleport 沒有 vendor-level 公開事故、但 07 案例庫的 identity / access 系列都是 PAM 設計的對照：

下一步路由

• 上游：7.2 身分與授權邊界、7.6 秘密管理與機器憑證治理
• 平行：HashiCorp Boundary / Tailscale SSH / Cloudflare Access
• 互補：Okta（IdP、user identity）、HashiCorp Vault（service secret）、SPIRE（workload identity）
• 偵測：Splunk / Elastic Security（session audit log 入 SIEM）
• 跨模組：8 事故處理 vendor 清單（compromise session 走 IR workflow）
• 官方：Teleport Documentation

服務定位

Boundary 的核心定位是 連線層級的存取仲介、不是傳統的 bastion host、也不是 identity-aware proxy。它把 連線發起權 收回控制面、user 不需要直接拿到 SSH key / DB password / cloud token、只需要對 Boundary 認證、由 Boundary 把 target 資源的網路位置 + Vault 動態簽發的 credential 在 session 開始時注入連線。

跟 Teleport 比、Boundary 走 network broker + dynamic credential injection、Teleport 走 identity-aware proxy + session recording。Teleport 是 看見每一個指令、可重播 的 PAM；Boundary 是 不存 credential、不錄影、靠 Vault short-lived token 來控制 blast radius。兩者解的是同一類問題（內部資源存取治理）、但工程取捨完全不同 — Boundary 把「攻擊者拿到 credential 也只有 minutes-level 有效期」當主要防線、Teleport 把「全部 session 留下不可否認證據」當主要防線。

跟 Tailscale SSH 比、Tailscale 走 mesh network + SSH-only、無 credential 仲介、無 dynamic injection；Boundary 走 broker 模式、支援 SSH / RDP / DB / TCP / HTTP 等多協議、且 credential 從 Vault 拉。跟 Cloudflare Access 比、Cloudflare 走 Zero Trust portal + identity-aware reverse proxy、是 HTTP-first；Boundary 是 protocol-agnostic broker、原生支援非 HTTP 協議（DB / SSH / RDP）。

關鍵張力：Boundary + Vault 組合的工程複雜度 ↔ 不靠 session recording 的審計可信度。已用 HashiCorp 生態（Terraform + Vault + Consul）的組織、Boundary 是 最後一塊拼圖；沒用 Vault 的組織用 Boundary 等於只剩一個 bastion 的弱化版、不如直接走 Teleport。合規強要求 keystroke audit 的場域、Boundary 預設不錄 session、要走 Enterprise add-on 才有、不如 Teleport first-class。

本章目標

讀完本頁、讀者能判斷：

1. Boundary 在 PAM stack 中承擔哪一段（broker / target / session）、哪些要外接（Vault 給 credential、IdP 給 auth、Enterprise add-on 給 session recording）
2. Controller + Worker + Multi-hop 拓樸怎麼對應實際網路分段（DMZ / internal / restricted subnet）
3. Vault Credential Library 怎麼設計、誰負責 host catalog、role / scope 怎麼劃
4. 何時用 Boundary、何時改走 Teleport / Tailscale SSH / Cloudflare Access 的取捨

最短判讀路徑

判斷 Boundary deployment 是否健康、最少看四件事：

• 是否真的接 Vault：Credential Library 是否從 Vault 拉 dynamic credential（DB / SSH cert / cloud token）、session 結束是否自動 revoke、還是仍有 static credential 存在 Boundary 或人手裡
• Scope 結構是否反映組織邊界：Global → Org → Project 的三層 scope、Org 對應 BU / tenant、Project 對應應用或環境；role / grant 是否按 Project 切、還是全部塞 Global scope 變共享密碼
• Worker 拓樸是否反映網路分段：Controller 在 control plane、Worker 在每個網路 segment（DMZ / internal / restricted DB subnet）、Multi-hop 是否走 segment-aware routing、還是把所有 worker 塞同一個 VPC
• Auth Method 是不是 IdP-backed：OIDC（Okta / Azure AD / Google）/ LDAP / Password — production 應該走 OIDC、Password auth method 只該存在於 break-glass

四件事任一缺失、就是 Privileged Access and Just-in-Time Authority 邊界的待補項目。

日常操作與決策形狀

Controller + Worker 拓樸：Controller 負責 control plane（auth、policy、session 管理、API endpoint）、Worker 負責 data plane（實際代理連線到 target）。Controller 通常 cluster 部署（3 個以上、HA）、Worker 按網路 segment 分散部署。Controller 從不直接連 target — user 跟 Controller 認證、Controller 告訴 user 走哪個 Worker、Worker 才實際代理連線。

Target + Host Set + Host Catalog：Target 是 user 看到的「可連對象」抽象（例如 prod-db-cluster）、Host Set 是 Target 對應的實際 host 集合、Host Catalog 是 host 的來源（static list 或從 cloud auto-discover）。Dynamic Host Catalog 可以從 AWS / Azure / GCP 用 tag 自動 enroll host、不需要手動維護 host list — 例如 tag:role=prod-db 的 EC2 自動進 prod-db-cluster Target。

Credential Library（Vault 整合）：Boundary 不存 credential、靠 Credential Library 從 Vault 拉。設計支援三種：Vault Generic（拉任意 Vault secret path）、Vault SSH Certificate（拉 Vault SSH CA 簽發的 short-lived cert）、Vault Database（拉 Vault Database Secret Engine 簽發的 DB user / password）。session 開始時 Boundary 拉 credential、注入連線、session 結束時 Vault 自動 revoke。這是 Boundary 的核心價值 — 沒接 Vault 等於丟掉 dynamic credential rotation 這個最大賣點。

Auth Method：支援 OIDC（OAuth2 / OpenID Connect、給 Okta / Azure AD / Google）、LDAP（給 internal directory）、Password（給 break-glass）。Production 預設走 OIDC、跟 IdP 同源、user lifecycle 隨 IdP 變動（離職 IdP 鎖、Boundary 自動失效）。Password auth method 只該存在於 break-glass account、密碼進 Vault、單獨 audit。

Role + Grant + Scope：Boundary 的權限模型是 scope-bound role、role 屬於某個 scope（Global / Org / Project）、grant 是 role 內的具體權限（例如 target=<id>;actions=authorize-session）。Scope 三層分別對應：Global — platform-level admin、Org — 某 BU 或 tenant、Project — 應用或環境（prod / staging / dev）。設計時把 role 按 Project 切、不要全部塞 Global scope 變共享密碼。

Session 生命週期：user 對 Boundary 認證（OIDC）→ list authorized target → 對某 target 發起 authorize-session、Boundary 從 Credential Library 拉 credential → user 透過 Boundary CLI / Desktop / SDK 連線、實際走 Worker 代理 → session 有 max duration（預設 8 小時、可調短）、過期自動斷 + Vault credential revoke。session metadata（誰、何時、target、worker、duration）一律 audit log。

Multi-hop Worker：跨網路 segment（例如 user 在 corp 網、target 在 DMZ → internal → restricted DB subnet）時、Boundary 支援 worker chain — corp Worker 連到 DMZ Worker、DMZ Worker 連到 internal Worker、internal Worker 連到 DB。每段 worker 只看得到下一段、不需要 VPN trunk 把整個網路打通。這是 Boundary 相對 Teleport / Tailscale 的網路工程優勢、特別適合金融 / 政府 / 製造業的多層網路分段。

核心取捨表

選 Boundary 的核心訴求：已用 HashiCorp 生態（特別是 Vault） + 多協議內部資源（不只 SSH、還有 DB / RDP / TCP） + 多層網路分段需要 Multi-hop、可以接受 session recording 不是 first-class。沒用 Vault 的組織、Boundary 失去最大價值、應該直接走 Teleport。

進階主題

Multi-hop Worker 跟網路分段：金融 / 政府常見三段網路（corp → DMZ → restricted）、傳統做法是打 VPN trunk 把整個網路扁平化、accept 大 blast radius。Boundary 用 worker chain 反向 — 每個 segment 部署一個 worker、worker 之間用 mTLS 認證、user 只進 corp worker、後面 hop 由 Boundary control plane 編排。每段 worker 不知道後一段的 target 細節、只知道下一段 worker 的位置。配對 Segmentation and Blast Radius Containment 的章節原則。

Dynamic Host Catalog：手動維護 host list 在 cloud-native 環境會壞 — auto-scaling group 起一台新 EC2、沒人去 Boundary 加 target。Dynamic Host Catalog 配 cloud provider plugin（AWS / Azure / GCP）、用 tag 自動 enroll：例如 tag:env=prod tag:role=app 的 EC2 自動進 prod-app Target、scale-down 也自動移除。這配 IaC（Terraform 管 tag）是 HashiCorp 生態一致性的核心賣點。

Session Recording（Enterprise 才有）：2023+ Boundary Enterprise 引入 session recording、支援 SSH 跟 RDP 的 keystroke + screen recording、output 加密存到 S3 / Azure Blob、metadata 走 audit。OSS Community Edition 沒有、只記 session metadata（who / when / what target / how long）。組織要 session recording 但又要 Boundary、要評估 Enterprise license cost vs Teleport license cost — 通常 Teleport 在 session recording 場景成本效益更好。

Vault credential brokering 設計：Boundary 連 Vault 的設計支援多種 secret engine — Database（Postgres / MySQL / Redis 等、簽 short-lived DB user）、SSH Certificate（簽 short-lived SSH cert）、AWS / Azure / GCP（簽 cloud STS token）、KV v2（拉靜態 secret、不推薦）。Production 預設用 dynamic engine、不要用 KV v2 — 靜態 secret 失去 Boundary 最大價值。Vault namespace / policy 設計要對齊 Boundary scope、否則 cross-scope credential 暴露變大問題。

HCP Boundary（HashiCorp Cloud Platform）：HashiCorp 託管的 SaaS 版、Controller 由 HashiCorp 管、user 只部署 Worker 到自己網路。優點是省去 Controller HA / upgrade 維運；缺點是 control plane 在 HashiCorp 雲、合規敏感場域要評估 data residency。SMB / 中型團隊適合走 HCP、大型 enterprise 通常 Self-hosted。

排錯與失敗快速判讀

• Session 拿到 credential 但 target 連不上：Worker 跟 target 之間網路不通、或 Worker 沒部署到 target 所在 segment — 檢查 Worker tag 跟 Target worker_filter、用 boundary workers list 確認 Worker 健康
• OIDC login 失敗：IdP redirect URI 沒對齊、或 IdP signing key 過期 — 對照 Microsoft Storm-0558 的啟示、Boundary OIDC auth method 依賴上游 IdP signing key、IdP 端 key rotation 不對 Boundary 通知會整批 session 認不過
• Vault credential 拉不到 / 過期太快：Boundary 服務帳戶在 Vault 的 policy 沒給 creds/<role> 權限、或 Vault 簽的 credential TTL 短於 session max duration — 對齊 TTL、加 Vault telemetry alert credential issuance 失敗
• Multi-hop 連線中斷：中間 hop 的 Worker 健康但 connection drop — 通常是中間 segment 的 firewall idle timeout 短於 session activity gap、調 firewall 或在 client 端開 keepalive
• Target 量爆炸 / role 管不動：所有 target 塞 Global scope、role 量線性漲 — 重構 scope 結構、按 Org / Project 切、role 從 Global 移到 Project 層
• Dynamic Host Catalog 漏 host：cloud tag 沒打 / IAM 沒給 Boundary 描述權限 — 檢查 cloud plugin 的 service account permission、加 catalog sync error 的 alert
• OSS Community 升 Enterprise 才發現缺 feature：選 OSS 之前沒確認需求 — session recording / SAML / 高級 RBAC / multi-region HA 都是 Enterprise 才有、評估時就要列清楚

何時改走其他服務

不在本頁內的主題

• Boundary CLI / Desktop / Terraform provider 的完整指令 reference
• HCP Boundary 跟 Self-hosted 的功能對照細節（HashiCorp 官方有 matrix）
• Vault 內部的 secret engine 設計（在 HashiCorp Vault 頁）
• OIDC / SAML 協議本身的攻擊面（2.3 SSO 攻擊面）
• Network segmentation 的整體設計（Segmentation and Blast Radius Containment）

案例回寫

Boundary 在 07 案例庫沒有直接 vendor-level 事件、但 PAM / credential rotation / IdP 相關 case 都是它的設計取捨對照：

下一步路由

• 上游：7.B Privileged Access and JIT Authority、7.B Segmentation and Blast Radius Containment
• 平行：Teleport、Tailscale SSH、Cloudflare Access
• 搭檔：HashiCorp Vault（Credential Library 核心）、Okta（OIDC IdP）
• 跨類：AWS IAM（cloud target 的 STS token 來源）、Terraform（target / scope / role 進 IaC）
• 跨模組：8 事故處理 vendor 清單（Boundary audit log → SIEM → IR routing）、2.3 SSO 攻擊面
• 官方：Boundary Documentation

服務定位

Tailscale 的核心定位是 WireGuard overlay mesh + identity-bound 連線、Tailscale SSH 是其上 取代 sshd 的 SSH 模組。底層是 Tailscale daemon（每台 device 跑、建立 WireGuard tunnel）+ Tailscale control plane（管 ACL、key exchange、IdP integration、node enrollment）。Tailscale SSH 不是把 OpenSSH 套上 VPN — 它是把 SSH server 換成 Tailscale daemon 內建版本、用 tailnet identity 取代 SSH key、ACL 跟 sshd 設定脫鉤。

跟 Teleport 比、Tailscale 走 zero-config + developer-friendly、Teleport 走 audit-first + compliance-friendly — Teleport session recording / RBAC / approval workflow 是 first-class、Tailscale Enterprise 才補 session recording、approval workflow 偏簡單。跟 Boundary 比、Boundary 是 network broker（client → broker → target、target 不在 client 網路上）、Tailscale 是 overlay network（client / target 都在 tailnet 上、直接點對點）；Boundary 配 Vault 發 dynamic credential、Tailscale 直接 bypass credential。跟 Cloudflare Access 比、Cloudflare Access 走 application-layer reverse proxy、Tailscale 走 network-layer mesh；application（HTTP / API）走 Cloudflare、機器存取（SSH / RDP / DB port）走 Tailscale。

關鍵張力：developer 易用性 ↔ audit / compliance 深度 是 Tailscale 客戶的最大 trade-off。Tailscale 把 SSH 變成「裝完 Tailscale 客戶端、加入 tailnet、不用設 sshd」、developer onboarding 從幾天縮到幾分鐘；但 session recording、approval workflow、keystroke audit 在 Enterprise tier 才有、且深度仍不及 Teleport。

本章目標

讀完本頁、讀者能判斷：

1. Tailscale 在 access stack 承擔哪一段（mesh network / identity-bound SSH / Funnel external access）、哪些要外接（Okta IdP、Splunk audit log、Teleport 補 session recording）
2. ACL JSON policy 的 ownership 設計（src / dst / group / tag、誰寫、誰 review、tag 命名空間如何治理）
3. Tailscale SSH vs Teleport vs Boundary vs Cloudflare Access 的選型判讀
4. 何時用 Tailscale、何時補上 Teleport（compliance）、何時補上 Boundary（dynamic credential）

最短判讀路徑

判斷 Tailscale SSH deployment 是否健康、最少看四件事：

• ACL 是否走 tag 而非 IP：production node 是否標 tag:prod-*、ACL 用 tag / group 寫（src: ["group:sre"]、dst: ["tag:prod-db:22"]）而非寫 device hostname；ACL JSON 是否進版控（Git → Tailscale GitOps integration）、change 經 PR review
• Identity provider 是不是組織 IdP：tailnet 是否綁 Okta / Google Workspace / Microsoft Entra ID、user 從 IdP SCIM 同步、離職時 IdP deprovision 是否連動 tailnet（不是手動撤 tailnet user）
• Tailscale SSH 是否取代 sshd：production node 是否關掉 OpenSSH 的 port 22 listener、只允許 Tailscale SSH（避免 fallback 到 SSH key auth、繞過 tailnet ACL）
• Audit log 是否進 SIEM：Tailscale audit log（device add / ACL change / SSH session start）是否串到 Splunk / Elastic Security、跟 IdP log correlation；Enterprise tier 的 SSH session recording 是否啟用

四件事任一缺失、就是 Identity Access Boundary 的待補項目。

日常操作與決策形狀

Tailnet 與 Node enrollment：Tailnet 是一個邏輯網路（一個組織通常一個）、Node 是加入 tailnet 的 device（laptop / server / container）。Enrollment 兩種路徑 — interactive（人類 device 跑 tailscale up、瀏覽器跳 IdP 登入）、auth key（ephemeral / reusable / preauthorized key、CI / IaC 用）。Production server 通常用 auth key + tag 加入、tag 在 enrollment 時就綁定、不能事後改。

ACL JSON policy：Tailscale ACL 是 HuJSON（JSON with comments）文件、由 acls / groups / tagOwners / ssh 區塊組成。acls 寫 action: accept + src + dst + proto + port、groups 把 user 抽成角色（group:sre、group:helpdesk）、tagOwners 控制誰能 mint 某個 tag、ssh 區塊定義誰能用 Tailscale SSH 連到哪些 tag（額外於 acls）。ACL 寫得好不好直接決定 lateral movement blast radius。

Tailscale SSH（取代 sshd）：Tailscale SSH 是 daemon 內建的 SSH server、user 連線時不出示 SSH key、Tailscale 用 tailnet identity（從 IdP 來）做 authn、用 ACL 的 ssh 區塊做 authz。SSH session 的 OS user 由 ACL 指定（users: ["root", "ubuntu"]）、不是 user 自己挑。意義是 SSH key rotation 從 lifecycle 移除、user 離職 IdP deprovision 後立即失去所有 SSH access。

Identity provider 整合：Tailscale 自身不存 password、user identity 完全外包給 IdP。Okta / Google Workspace 通常用 SCIM 同步 user + group、GitHub SSO 走 OAuth、Microsoft Entra ID 走 SAML。Group 從 IdP 同步進 tailnet 後、ACL 直接用 group:sre、group:contractor。IdP 的 MFA / Conditional Access policy 自動套用到 tailnet authn。

Tag-based machine identity：Tag 是 Tailscale 的 machine identity primitive、語意接近 SPIRE workload identity（但 Tailscale-specific、不是 SPIFFE 標準）。Production 用 tag 把 node 分類（tag:prod-db、tag:prod-app、tag:ci-runner）、ACL 用 tag 寫規則。Tag 在 enrollment 時 bind、之後不能改（要重新 enroll）；tagOwners 控制誰能 mint 該 tag、防止 dev tag 升 prod tag。

Subnet Router 與 Exit Node：Subnet Router 把 on-prem subnet（例如 10.0.0.0/16 的舊資料中心）route 到 tailnet、不用在每台舊機器裝 Tailscale daemon — 適合 legacy infra migration。Exit Node 把所有流量（不只 tailnet）走某個 node 出去、適合 remote worker 需要從固定 IP 出網。兩者都是 mesh 之外的擴展、不是 first-class、容易擴大 blast radius 要謹慎用。

Funnel（external HTTPS access）：Funnel 把 tailnet 上的 internal service 暴露到 internet（透過 Tailscale relay、Tailscale 出 TLS cert）、適合 webhook receiver、dev preview environment、demo URL。Production-grade external access 應該走 Cloudflare Access 或 reverse proxy + WAF — Funnel 沒有 WAF、bot protection、rate limit，是 zero-config 暴露、不是 production hardened ingress。

跟 OS firewall 互動：Tailscale 是 overlay network、不取代 OS firewall。Production node 應該用 OS firewall（iptables / nftables / Windows Firewall）封鎖 非 tailnet 流量到 port 22 / 3306 / 5432、只允許 tailscale0 介面進來；不然攻擊者拿到 node IP 後仍能繞過 ACL 直接 SSH。

核心取捨表

選 Tailscale SSH 的核心訴求：developer 易用性 + zero-trust mesh + 願意接受 Tailscale 控制面信任、且 audit / compliance 要求是中度而非極致（SOC 2 Type II + 內部 SOX 等級就配 Enterprise tier session recording、HIPAA / FedRAMP / 重 compliance 走 Teleport）。

進階主題

Tailscale SSH session recording（Enterprise）：2023 後 Enterprise tier 提供 SSH session 錄影、存到組織自己的 S3 / GCS（不是 Tailscale 控制面）、用 recorder node（tag:tailscale-recorder）攔流量寫盤。意義是 audit 不再依賴 OS-level 工具（auditd / OSSEC）；但跟 Teleport 比、Tailscale recording 仍偏簡單、approval workflow 是基本版、structured query 跟 keystroke replay UI 不如 Teleport。

Subnet Router 的 blast radius：Subnet Router 把整個 subnet route 到 tailnet、ACL 控制粒度從 device-level 退到 subnet-level（除非搭 tag）— 一台 Subnet Router 給太多人用就是 jump host 復活。production 應該 每個 subnet 至少兩個 Subnet Router（HA）、tag 區分（tag:subnet-router-prod）、ACL 限定誰能透過它走。

Headscale（OSS control plane alternative）：Headscale 是社群維護的 Tailscale control plane OSS 重實作、self-hosted、跟官方 Tailscale client 相容。適用 資料主權 / air-gapped / 不信任 Tailscale 控制面 場景。代價是 ACL JSON 編輯器 / GitOps / SCIM / IdP integration 都要自己拼、沒有官方 SaaS 的 console UX 跟 SLA。production 用 Headscale 通常配 SPIRE workload identity 補 machine identity。

跟 SPIRE workload identity 對照：Tailscale tag 是 Tailscale-specific 的 machine identity primitive、語意接近 SPIRE 的 SPIFFE ID（spiffe://example.org/prod-db）；差異在 SPIRE 走 SPIFFE 開放標準、跨 platform（Kubernetes / VM / serverless）、tag 只在 tailnet 內有意義。重 multi-platform workload identity 走 SPIRE、SSH access 為主走 Tailscale tag。

Just-In-Time access pattern：Tailscale 預設是 standing access（user 在 group:sre、永遠能 SSH 到 prod-db）、不是 JIT。要做 JIT 通常 IdP 端做（Okta Workflows 加 user 進 group:sre-oncall、SCIM 同步進 tailnet、ACL 給 group:sre-oncall 對 prod-db 的 SSH 權限）、或 Tailscale API 自寫 ACL 寫入腳本。Teleport / Boundary 有 first-class JIT approval、Tailscale 要自己拼。

排錯與失敗快速判讀

• ACL 改錯把全公司鎖在外面：ACL JSON 寫錯 default deny 規則、Tailscale 控制面套用後沒人能連 — 用 Tailscale 控制面的 ACL preview / test 功能、production 走 GitOps PR review、保留 admin-emergency-access group bypass
• 離職員工還能 SSH：IdP deprovision 沒連動 tailnet（手動管 user）— 改走 SCIM 同步 + IdP group binding、ACL 用 group 而非個別 user
• OpenSSH 還在 listen port 22 給 fallback：node 沒關 sshd、攻擊者拿到 IP 後用 SSH key 繞過 tailnet ACL — production node 關掉 sshd、OS firewall 只允許 tailscale0 介面的 22 port
• tag 被誤升 prod：dev user 自己 mint tag:prod-db 給 node、ACL 給 prod-db SSH 權限就此擴散 — tagOwners 限定 tag:prod-* 只有 group:sre 能 mint
• Funnel 暴露 internal service：dev 為了 demo 開 Funnel、忘了關、production data 外洩 — Funnel 走 audit log + alert、預設不該開、要開走 short-lived auth key + tag isolation
• Subnet Router 變新 jump host：一台 Subnet Router 給全公司用 legacy subnet、ACL 退到 subnet-level — tag 區分 router、ACL 限定誰能透過它、HA 跑兩台以上
• Audit log 沒進 SIEM：Tailscale console 看 audit log 很慢、跟 IdP / cloud control plane 沒 correlation — 啟用 Tailscale audit log streaming 到 Splunk / Elastic Security、跨來源 correlation

何時改走其他服務

不在本頁內的主題

• WireGuard 協定本身的密碼學細節跟 NAT traversal 機制
• Tailscale 計費 tier 的逐項功能對照（看 Tailscale 官方 pricing page）
• Headscale 完整部署 + GitOps + SCIM 自拼方案
• Tailscale 跟 OPNsense / pfSense 等傳統 VPN gateway 的整合
• Tailscale 內網 DNS（MagicDNS）跟 split-horizon DNS 的細節

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.3 入口治理與伺服器防護
• 平行：Teleport、Boundary、Cloudflare Access
• 下游：SPIRE（workload identity 補位）、HashiCorp Vault（dynamic credential 補位）
• 跨類：Okta（IdP 來源）、Splunk（audit log SIEM）、Cloudflare WAF（external HTTPS production ingress）
• 跨模組：8 事故處理 vendor 清單（tailnet compromise IR routing）
• 官方：Tailscale Documentation、Tailscale SSH、Headscale

服務定位

Cloudflare Access 的核心責任是 application-level 認證 + authorization、不是 network-level routing。一個 Application（hostname / subdomain）對應一組 Access Policy（rule with identity / device / network condition）、user 從 Okta / Google / Azure AD / GitHub 等 IdP 認證後、policy engine 決定能不能進、不能進連到 application backend 都沒機會。它是 Cloudflare Zero Trust suite 的核心、跟 WARP client（device agent）、Gateway（DNS / HTTP filtering、取代 Cisco Umbrella 類）、Argo Tunnel（origin-side outbound、不開 ingress port）組成完整 SASE / Cloudflare One 平台。

跟 Teleport 比、Cloudflare Access 走 application-layer + Cloudflare edge、Teleport 走 infrastructure-layer + 完整 session recording。需要 keystroke / RDP / kubectl 完整錄影做合規（PCI / HIPAA）走 Teleport、需要把所有 internal web app 收進統一 ZTNA portal 走 Cloudflare Access、兩者並存常見：Teleport 管 SSH / DB / Kubernetes、Cloudflare Access 管 internal web。跟 Tailscale SSH 比、Tailscale 是 mesh VPN + device-to-device WireGuard、Cloudflare Access 是 application proxy via edge。Tailscale 適合 developer 直接 SSH 到雲機、Cloudflare Access 適合 internal app（GitLab / Jenkins / 內部 dashboard）統一收口。跟 Cloudflare WAF 的關係：同 Cloudflare 控制面、共用 API token / Audit Log / Logpush、但解不同問題 — WAF 防 public app（attacker 從外打 production web）、Access 防 internal app（員工 / 廠商存取後台）、兩者常在同一個 Cloudflare account 共存。

關鍵張力：Cloudflare 控制面信任成本 ↔ 統一 ZTNA portal 的工程紅利 是 Cloudflare Access 客戶的長期取捨。Cloudflare 自家 control plane 出事（Cloudflare 2023 control plane token）會直接打到 Access policy 變更權、客戶側必須有非 Cloudflare 路徑的 break-glass。

本章目標

讀完本頁、讀者能判斷：

1. Cloudflare Access 在 ZTNA / PAM stack 中承擔哪一段（application access）、哪些要外接（Teleport 管 infrastructure session、Okta 管 IdP source of truth）
2. Application + Access Policy + Argo Tunnel 三者的 ownership 設計（誰建 Application、誰寫 policy、誰跑 cloudflared agent）
3. Cloudflare control plane 信任邊界 — 自家事故的 blast radius 跟客戶側 break-glass 預案
4. 何時用 Cloudflare Access、何時走 Teleport / Tailscale / Zscaler 的取捨

最短判讀路徑

判斷 Cloudflare Access deployment 是否健康、最少看四件事：

• 誰能改 Access Policy：Cloudflare account 的 Super Admin / Access Admin 人數、policy change 是否走 Terraform / API + PR review、是否有 IdP claim 跟 Cloudflare group 雙重 enforcement
• Application 收口完整度：internal web / SSH / RDP / API 是否都進 Application 清單、是否還有 bypass Cloudflare 直連 origin 的暴露 IP、Argo Tunnel 是否強制（origin 防火牆只開 cloudflared outbound、不開 ingress）
• Device Posture / Service Auth 治理：human user 是否有 WARP + Device Posture 檢查（OS 版本 / EDR / disk encryption）、non-human（CI / 機器）是否走 Service Auth（mTLS cert / service token）而非共用 user account
• Logpush + break-glass：Access event / Audit Log 是否 Logpush 到 Splunk 或外部 SIEM、Cloudflare 自家 control plane 出事時是否有 非 Cloudflare 路徑可進關鍵 application（例如 emergency bastion 走獨立 IdP）

四件事任一缺失、就是 Identity and Access Boundary 邊界的待補項目。

日常操作與決策形狀

Application + Access Policy：Application 是 first-class concept、對應一個 hostname（gitlab.internal.example.com）或一組 subdomain。Application 綁多個 Access Policy、每個 policy 是 Allow / Block / Bypass rule、條件可組合 identity（IdP group / email / SAML claim）、device（Device Posture 結果 / WARP enrolled）、network（country / IP range / Service Token）。policy 順序決定優先級、第一個 match 的生效。Production 寫法是 deny by default + allow specific group、不是 allow all + block bad。

IdP integration：Cloudflare Access 不存身份、只接 IdP — SAML / OIDC 對 Okta / Azure AD / Google Workspace、OAuth 對 GitHub / GitLab、One-Time PIN 對外部廠商（沒 IdP 的合作方）。同一個 Application 可接多 IdP、policy 用 identity.email ends with @vendor.com 區分。IdP 是 source of truth、Cloudflare 是 enforcement point — IdP 出事（Okta / Azure AD 故障或被打）會直接擋住所有 Access user 登入、break-glass 預案必要。

Argo Tunnel（cloudflared）：internal app 不開 ingress port、不需要 public IP、由 cloudflared agent 在 origin 主動建 outbound tunnel 到 Cloudflare edge。攻擊面從「IP + port + WAF rule」收成「cloudflared agent + Tunnel token」— attacker 從外掃不到 origin，必須先拿到 Tunnel token 或 compromise cloudflared host。Argo Tunnel 的 token 是高敏 secret、應該存 Vault 或 cloud secret manager、定期 rotate。

Browser-based SSH / RDP / VNC：Cloudflare Access 對 SSH / RDP / VNC 提供 browser-based render — user 不裝 SSH client、瀏覽器直接連、session 經 Cloudflare edge proxy。可 log session metadata（user / app / time）但 不像 Teleport 完整錄 keystroke / 螢幕。合規場景（PCI 要求 session recording）需要外接 Teleport 或自己跑 session recording proxy、Cloudflare Access 解決的是 access enforcement 不是 audit replay。

Service Auth（non-human access）：CI runner / 機器人 / API client 走 Service Auth、不需要 user identity。兩種模式：mTLS（client cert + Cloudflare 驗 CA）、Service Token（HTTP header 帶 CF-Access-Client-Id + CF-Access-Client-Secret）。token 進 Vault 或 GitHub Actions secret、定期 rotate、access log 標 service token ID 做事後追蹤。

Device Posture：跟 WARP client / Gateway 整合、policy 可加 device 條件 — OS 版本最低、EDR（CrowdStrike / SentinelOne）running、disk encryption enabled、device certificate 已 enrolled。Device Posture check fail 時 deny access 或 fallback 到只讀 application。對應 zero-trust workforce architecture 的章節原則。

Gateway DNS / HTTP filtering：Cloudflare Gateway 是 secure web gateway（SWG）、取代 Cisco Umbrella / Zscaler ZIA 類。WARP client 把 device DNS / HTTP traffic 導到 Gateway、policy 過濾 malicious domain / category / DLP。跟 Access 共用 Cloudflare 帳號、policy 跨 Access + Gateway + WARP 統一 — 這是 Cloudflare One / SASE 的核心賣點。

Logpush 進 SIEM：Access event（login / policy decision / session）+ Audit Log（policy change / admin action）透過 Logpush 推到 S3 / GCS / Splunk HEC / Datadog / Elastic。跟 Cloudflare WAF 共用同一個 Logpush job 配置、SIEM 端做 cross-product correlation（WAF block + Access deny 同 IP）。

核心取捨表

選 Cloudflare Access 的核心訴求：application-layer ZTNA 取代 VPN + internal web app 為主 + 偶爾 browser SSH/RDP + 已用 Cloudflare WAF / CDN 控制面。需要 infrastructure-level session recording 走 Teleport、developer SSH mesh 為主走 Tailscale、要全 SASE / SWG / CASB 套裝走 Zscaler。

進階主題

Service Auth 的 non-human access 設計：CI / 機器人 / 第三方 API client 不該共用 user account、改走 Service Token 或 mTLS。設計重點：token 不進 git（Vault / GitHub Actions secret）、per-service token（不共用、追蹤責任）、rotation lifecycle（90 天 / 半年 rotate）、access log 標 token ID（事後追責）。token leak 的處理是 rotate + audit log review、不是 all-users password reset。

Device Posture + EDR 整合：Gateway / WARP 可接 CrowdStrike Falcon / SentinelOne / Microsoft Defender for Endpoint 的 device health、policy 可寫 require posture: crowdstrike.running == true AND crowdstrike.last_check < 1h。意義是 endpoint compromise 時 EDR 標紅、Access policy 自動 deny — 不需要 SOC 手動把 user disable。前提是 EDR fleet coverage 接近 100%、不然 fallback 設不好會誤殺。

Cloudflare One（Access + WARP + Gateway + Magic Transit）：Cloudflare 把 ZTNA + SWG + CASB + 網路骨幹整成 SASE 套裝、競爭對手是 Zscaler / Netskope / Palo Alto Prisma Access。買整套的紅利是 policy / log / IdP 統一、痛點是 Cloudflare 控制面信任成本指數放大 — 一個 admin 角色失控影響 Access + Gateway + WAF + DNS 全部、不只是單一產品。

跟 Cloudflare WAF 共用 control plane 的取捨：紅利是同一 Logpush job / 同一 API token 管理 / 同一 Audit Log、SIEM 端 correlation 容易。信任成本是 Cloudflare 2023 control plane token 那類事故會同時影響 WAF rule + Access policy + DNS、客戶側必須有 non-Cloudflare break-glass（例如保留一條 emergency bastion 走獨立 IdP + 獨立網路、不經過 Cloudflare edge）。

排錯與失敗快速判讀

• User 一進 Application 就被 deny：policy 順序錯（Block rule 在 Allow 前面 match）、或 IdP group claim 沒帶到 — 看 Access log 的 decision_reason、確認 policy 順序跟 IdP claim mapping
• Argo Tunnel 斷線 / 找不到 origin：cloudflared 程序掛或 token 過期、origin 防火牆把 outbound 443 擋了 — 重啟 cloudflared、確認 outbound 規則、token rotate 後重新 deploy
• Service Token 大量 leak / 在 GitHub repo 出現：CI secret 設定錯放成 plaintext、或第三方 vendor commit 了 — Cloudflare dashboard rotate token、audit log 找受影響時間窗、補 secret scanning（GitHub Advanced Security / Trivy）
• Device Posture 把合法 user 鎖在外：EDR agent 暫時離線或 OS 升級導致 posture check fail — fallback 設 graceful（降級到只讀 / 加 step-up MFA）、不是直接 deny；EDR fleet coverage 沒到位前不要 hard enforcement
• IdP 出事 Access user 全進不來：Okta / Azure AD downtime 把 Access login 全鎖死 — break-glass 走 Service Token + 緊急 Application（不接 IdP、只接 mTLS / token），預先 staging tested
• Bypass 流量直連 origin：Application 收口不完整、origin 還有 public IP + 沒設 firewall 只接 Cloudflare IP — Argo Tunnel 收完、origin firewall 只允許 Cloudflare IP range 或完全只開 cloudflared outbound
• Cloudflare control plane 出事：Cloudflare 自家 admin token / control plane 被打、客戶側 Access policy 暫時改不了或被偷改 — 預案：保留 非 Cloudflare emergency bastion + 關鍵 application 的 Logpush 進外部 SIEM（不只 Cloudflare dashboard）

何時改走其他服務

不在本頁內的主題

• Cloudflare WARP client 完整部署 / device enrollment 細節
• Gateway DNS / HTTP filtering 完整 policy 語法
• Cloudflare One / Magic Transit / Magic WAN 的網路骨幹細節（屬 SD-WAN / SASE 整套架構、不在 ZTNA 範圍）
• cloudflared agent 進階配置（multi-region / HA / load balancing）
• Cloudflare account / API token 管理本身（屬 Cloudflare 平台治理、跨產品共用）

案例回寫

Cloudflare Access 在 07 案例庫的關聯來自 Cloudflare 控制面信任 跟 IdP 上游事故傳導：

下一步路由

• 上游：7.2 身分與授權邊界、zero-trust workforce architecture
• 平行：Teleport、Tailscale SSH、Boundary
• 下游：Cloudflare WAF（共用 control plane）、Splunk / Elastic Security（Logpush 目的地）
• 跨類：Okta / Auth0（IdP source）、HashiCorp Vault（Tunnel token / Service Token 儲存）
• 跨模組：8 事故處理 vendor 清單（Access deny / 異常登入 routing）、5 deployment vendors（Argo Tunnel + CI 部署整合）
• 官方：Cloudflare Zero Trust Documentation