Teleport 基础设施零信任访问与审计平台建设
Teleport 以身份为中心统一访问 SSH 服务器、Kubernetes、数据库、内部 Web 应用和 Windows 桌面，并通过短期证书、SSO、RBAC 和会话审计减少长期账号与跳板机风险。它不是简单的 Web SSH 页面：一旦成为统一入口，Auth Service、Proxy Service、状态后端、会话录像和身份提供商都会进入关键访问链路。
一、核心架构
- Auth Service：身份、证书颁发、角色、集群状态和审计；
- Proxy Service：面向客户端的统一入口、反向隧道和协议代理；
- Agent/Service：注册服务器、Kubernetes、数据库和应用；
- 状态后端：保存资源、角色和审计事件；
- 对象存储：保存会话录像；
- Identity Provider：OIDC、SAML 或其他企业身份源。
用户 / tsh / 浏览器
│ TLS / ALPN
Proxy Service
│
Auth Service ── 状态与审计后端
│ └─ 会话录像对象存储
反向隧道 / Agent
│
服务器、K8s、数据库、应用、桌面
TLS Routing 可通过 443 端口承载多协议，简化防火墙，但负载均衡必须按官方要求工作在合适层次，不能随意终止和重建协议流量。
二、生产高可用拓扑
Auth 和 Proxy 应各部署多个实例，跨主机或可用区。Proxy 前使用四层负载均衡，Auth 使用内部四层入口。状态后端和对象存储必须独立高可用。
规划要点：
- 公网只暴露必要 Proxy 入口；
- Auth 仅允许 Proxy 和管理网络访问；
- 启用 TLS Routing 时验证 ALPN；
- 证书自动续期采用可靠 DNS-01 或企业 PKI；
- 状态与会话存储加密、备份并设置保留；
- 跨地域代理和受信集群单独设计；
- Agent 使用出站反向隧道穿越防火墙。
社区版与企业版能力、许可证和高可用支持存在差异，设计前必须核对当前官方功能矩阵，不能把商业能力写入社区版实施方案。
三、身份源与账号生命周期
优先接入企业 IdP，并使用 MFA。用户在 IdP 被禁用后，Teleport 侧的角色映射、活动证书和本地账号也要有处置流程。
身份治理包括：
- 禁止共享个人账号；
- 管理员使用独立高权限身份；
- 本地 Break Glass 账号离线保管；
- 自动化使用 Bot/Machine Identity，而非个人证书；
- 离职和岗位变化自动回收；
- 定期复核角色、访问申请和例外；
- 记录 IdP Group 到 Teleport Role 的映射。
短期证书降低长期密钥泄露风险，但签发权限和会话 Cookie 同样需要保护。
四、RBAC 与访问请求
角色应基于资源标签而不是逐台服务器硬编码。建立统一标签字典：环境、业务、地域、数据等级、负责人和资源类型。
kind: role
version: v7
metadata:
name: prod-readonly
spec:
allow:
node_labels:
env: prod
logins: [readonly]
高风险权限使用 Access Request/审批方式临时授予，并设置有效期、审批人和理由。不要创建永久 *:* 管理角色。定期查找没有命中资源的失效规则和范围过大的通配符。
五、SSH 访问治理
Teleport 用短期证书替代分散 SSH Key。服务器接入可采用 Teleport SSH Service 或 OpenSSH 证书集成，选择前确认操作系统、命令审计和升级路径。
应治理：
- 允许的 Linux Login；
- root 和 sudo；
- 文件传输；
- 端口转发；
- Agent Forwarding；
- 空闲超时与最大会话时长；
- 主机标签和所有者；
- 会话录像与命令事件。
会话录像不是防止误操作的唯一措施。高危命令还需 sudo、双人审批、变更单和操作窗口。
六、Kubernetes 访问
Teleport 可代理 Kubernetes API，把 SSO 身份映射到 Kubernetes User/Group。需要同时设计 Teleport Role 和 Kubernetes RBAC，避免两层权限叠加后过宽。
生产建议：
- 每个集群有稳定名称与标签；
- prod 与 test 使用不同角色；
- 禁止默认映射到
system:masters； - 审计
kubectl exec、端口转发和 Secret 读取； - 限制跨集群通配符；
- 集群证书和 ServiceAccount 定期轮换；
- 验证 Proxy 到 API Server 的网络和 SNI。
七、数据库与应用访问
数据库访问代理可以把短期身份用于 PostgreSQL、MySQL、MongoDB 等，但数据库内部权限仍需最小化。区分数据库服务、数据库名、数据库用户和 Teleport 角色。
内部应用接入后可使用 SSO 和审计，但应用自身权限不能完全由入口替代。WebSocket、长连接、回调 URL、上传大小和 Cookie 域需要专项测试。
应用域名通常需要通配 DNS 和证书，避免为每个应用人工维护入口。
八、Machine Identity
CI/CD、自动化和服务访问不应使用人员身份。为 Bot 定义独立角色、资源标签、TTL 和发行方式，限制能签发的凭据类型。
机器身份凭据要短期化、自动轮换，并保护加入 Token。发现 Token 泄露时不仅删除 Token，还要审查已注册资源和已签发证书。
九、会话录像与审计
会话录像、事件日志和身份信息属于敏感审计数据。对象存储应启用加密、版本控制、访问审计、保留策略和不可变保护。只有审计与安全人员可访问录像。
监控以下事件：
- 登录失败与 MFA 失败；
- 高权限角色签发；
- Access Request 申请和审批；
- 新资源注册；
- 角色和连接器变更；
- 会话录像上传失败；
- 非工作时间访问；
- 大量文件传输；
- Break Glass 使用。
时间同步必须可靠，否则跨系统审计无法对齐。
十、证书与 PKI
Proxy 公网证书、Teleport 集群 CA、主机证书、用户证书和 IdP 证书有不同生命周期。建立到期监控、轮换演练和旧 CA 过渡期。
CA Rotation 可能影响所有 Agent 和客户端，必须按官方阶段执行。不要在事故中直接替换整个数据目录。备份 CA 私钥时使用独立密钥保护和严格访问审计。
十一、监控与容量
监控 Auth/Proxy 实例、请求延迟、证书签发、反向隧道、连接数、状态后端、会话上传、登录失败和资源注册。
容量取决于：
- 注册资源数；
- 并发会话；
- 录像流量；
- Kubernetes 和数据库连接；
- Trusted Cluster/多地域；
- 审计保留；
- IdP 延迟。
按官方当前扩展指南压测，不要用单节点体验环境推算生产。
十二、备份与灾难恢复
备份包括：状态后端、会话录像、配置、角色、连接器、证书/CA、DNS、负载均衡、部署制品和资源标签清单。
恢复演练：
- 恢复状态和对象存储；
- 使用兼容版本启动 Auth；
- 验证 CA、角色、连接器和资源；
- 启动 Proxy 并测试负载均衡；
- 验证 SSH、Kubernetes、数据库和应用；
- 检查旧 Agent 重连；
- 验证审计与录像；
- 测试 Break Glass。
如果 Teleport 故障导致完全无法管理服务器，必须有受控的带外和紧急访问路径。
十三、升级策略
Teleport 客户端、Proxy、Auth 和 Agent 之间有版本兼容边界。升级前查看官方升级顺序和版本跨度，备份状态，先验证 IdP、证书、所有协议代理和会话录像。
逐步升级，保留至少一个健康实例，不要同时重启全部 Auth 或 Proxy。升级完成后检查 Agent 在线率和旧客户端兼容性。
十四、故障排查
登录成功但看不到资源
检查 IdP Claim、角色映射、资源标签、Allow/Deny 和角色 TTL。
Proxy 连接超时
检查 L4 负载均衡、TLS Routing/ALPN、证书、DNS、端口和 Proxy 到 Auth 的 gRPC。
Agent 离线
检查反向隧道、出口防火墙、Token、CA、时间和版本兼容。
会话有记录但录像缺失
检查对象存储权限、网络、上传队列、生命周期和审计后端。
数据库连接失败
区分 Teleport 角色、数据库用户、TLS、协议端口、数据库内部权限和网络。
十五、生产检查清单
- [ ] Auth、Proxy 和后端均高可用；
- [ ] 公网仅暴露必要 Proxy 端口；
- [ ] SSO、MFA 和离职回收已验证；
- [ ] 角色基于统一资源标签；
- [ ] 高权限使用限时审批；
- [ ] 自动化使用机器身份；
- [ ] 会话录像与审计加密并备份；
- [ ] CA 和公网证书有到期告警；
- [ ] SSH/K8s/数据库/应用分别做权限测试；
- [ ] Break Glass 受控且定期演练；
- [ ] 升级核对全组件兼容；
- [ ] 已完成完整灾难恢复演练。