Teleport 实战：3 步部署零信任访问网关，统一管理 SSH/K8s/数据库

痛点：传统堡垒机 + VPN 的三重困局

你的团队是不是也面临这样的局面？

SSH 密钥散落一地 — 每台服务器都有一堆 authorized_keys，员工离职后没人敢删，也不知道哪些还在用
VPN 一旦接入就是全网暴露 — 开发拿到 VPN 账号后能摸到生产数据库，横向移动毫无阻拦
审计形同虚设 — 堡垒机只记录了"谁登录了"，至于登录后执行了什么，出了事故才发现日志早就轮转没了

传统方案的核心问题是：认证和授权是割裂的。VPN 管网络层准入，堡垒机管 SSH 登录，数据库有自己的账号体系，Kubernetes 又是另一套 RBAC。每多一层基础设施，就多一套凭据要管理。

Teleport 的思路是用短时证书 + 统一身份替代所有静态凭据，把 SSH、Kubernetes、数据库、Web 应用的访问收归一个平面。

方案：Teleport 的零信任架构

Teleport 是一个开源（Community Edition）的基础设施访问网关，核心架构三个组件：

组件	职责
Auth Service	签发短时证书（默认 12 小时过期），管理 RBAC 策略
Proxy Service	统一入口，反向代理所有协议（SSH/K8s API/数据库协议/HTTPS）
Agent	部署在目标节点上，注册到 Auth Service，建立反向隧道

关键设计：用户通过 SSO 登录后，Auth Service 签发一张包含角色信息的短时 X.509 证书。这张证书就是唯一凭据 — 不需要 SSH 密钥、不需要数据库密码、不需要 K8s kubeconfig 静态 Token。证书过期后必须重新认证，离职员工即时失去所有访问权限。

实操：3 步完成核心部署

第 1 步：部署 Teleport 集群（Auth + Proxy）

在一台 Linux 服务器上安装 Teleport：

# Ubuntu/Debian
curl -O https://cdn.teleport.dev/teleport-community-v17-linux-amd64-deb-installer.sh
bash teleport-community-v17-linux-amd64-deb-installer.sh

# 生成初始配置
sudo teleport configure --cluster-name=ops.example.com \
    --public-addr=ops.example.com:443 \
    --acme --acme-email=admin@example.com \
    -o /etc/teleport.yaml

# 启动服务
sudo systemctl enable teleport && sudo systemctl start teleport

# 创建管理员用户
sudo tctl users add admin --roles=editor,access --logins=root,ubuntu

--acme 参数让 Teleport 自动从 Let's Encrypt 获取 TLS 证书，省去手动配证书的麻烦。

第 2 步：注册目标节点（SSH + 数据库）

注册 SSH 节点：

在 Auth 节点上生成 Join Token：

# 生成一次性 Token（有效期 15 分钟）
sudo tctl tokens add --type=node --ttl=15m

在目标服务器上安装 Agent 并加入集群：

# 安装同版本 teleport
sudo teleport node configure \
    --token=<join-token> \
    --auth-server=ops.example.com:443 \
    --node-name=prod-web-01 \
    -o /etc/teleport.yaml

sudo systemctl enable teleport && sudo systemctl start teleport

注册 MySQL 数据库：

sudo tctl tokens add --type=db --ttl=15m

# 在数据库旁部署 Agent
sudo teleport db configure create \
    --token=<join-token> \
    --auth-server=ops.example.com:443 \
    --name=prod-mysql \
    --protocol=mysql \
    --uri=mysql-master.internal:3306 \
    -o /etc/teleport.yaml

Teleport 通过短时证书连接数据库，MySQL 8.0+ 原生支持 X.509 证书认证，无需在 Agent 上存储数据库密码。

第 3 步：配置 RBAC 策略

创建角色文件 dev-role.yaml：

kind: role
version: v7
metadata:
  name: developer
spec:
  allow:
    # SSH：只能访问 env=staging 的节点，只能用 ubuntu 登录
    node_labels:
      env: staging
    logins: [ubuntu]

    # 数据库：只能访问 staging 库，且只有只读权限
    db_labels:
      env: staging
    db_names: ["app_staging"]
    db_users: ["readonly"]
    db_roles: ["ro"]

    # Kubernetes：只能访问 staging 命名空间
    kubernetes_labels:
      env: staging
    kubernetes_resources:
      - kind: pod
        namespace: staging
  options:
    # 会话最长 8 小时，空闲 30 分钟自动断开
    max_session_ttl: 8h
    client_idle_timeout: 30m

sudo tctl create -f dev-role.yaml
# 将角色分配给用户
sudo tctl users update dev-user --set-roles=developer

日常使用：

# 登录（会跳转 SSO 或 Web 认证）
tsh login --proxy=ops.example.com

# SSH 连接（证书自动鉴权，无需密钥）
tsh ssh ubuntu@prod-web-01

# 连接数据库
tsh db connect prod-mysql --db-user=readonly --db-name=app_staging

# 访问 Kubernetes
tsh kube login staging-cluster
kubectl get pods -n staging

避坑指南

坑 1：节点时钟不同步导致证书校验失败

Teleport 的短时证书对时间敏感，节点时钟偏差超过 30 秒就会报 certificate is not yet valid 或 certificate has expired。

# 所有节点必须配 NTP
sudo timedatectl set-ntp true
# 验证时间偏差
chronyc tracking | grep "System time"
# 偏差应 < 0.01 秒

生产建议：在监控中加一条 node_timex_offset_seconds > 0.05 的告警。

坑 2：审计日志存本地磁盘，集群扩容后丢日志

默认配置下审计日志和会话录像存在 Auth 节点的 /var/lib/teleport 目录。Auth 节点挂了或扩展为多节点后日志会分散丢失。

# teleport.yaml — 将审计日志存到 S3
teleport:
  storage:
    type: s3
    region: ap-northeast-1
    bucket: teleport-audit-logs
    audit_events_uri: "dynamodb://teleport-events"
    audit_sessions_uri: "s3://teleport-session-recordings/sessions"

生产建议：Day 1 就配好外部存储，别等日志丢了再迁移。

坑 3：Join Token 泄露 = 任意节点可加入集群

默认的静态 Token 如果写进了 Ansible Playbook 或 Git 仓库，任何人拿到都能往集群里注册节点。

# 不要用静态 Token！改用短时 Token
tctl tokens add --type=node --ttl=10m

# 更安全：用 IAM Join Method（AWS 环境）
# 节点用自身 IAM 角色身份加入，无需 Token

# iam-token.yaml — AWS IAM Join Method
kind: token
version: v2
metadata:
  name: iam-join
spec:
  roles: [Node]
  join_method: iam
  allow:
    - aws_account: "123456789012"
      aws_arn: "arn:aws:sts::123456789012:assumed-role/TeleportNodeRole/*"

总结

维度	传统方案（堡垒机 + VPN）	Teleport
凭据管理	SSH 密钥 + DB 密码 + K8s Token	短时证书，统一身份
权限粒度	网络层面（能/不能连）	资源标签级 RBAC
审计能力	登录日志	全量会话录像 + 命令审计
离职处理	逐台清理密钥和账号	SSO 停用即刻生效
横向移动风险	VPN 接入后可探测全网	仅授权资源可达

Teleport 的核心价值不是"又一个堡垒机"，而是把访问控制从网络层提升到身份层。短时证书消灭了静态凭据这个最大攻击面，统一 RBAC 让权限管理终于有了单一事实来源。

如果你的团队还在用"VPN + 堡垒机 + 一堆密钥文件"的组合，建议找一个非生产环境先跑起来体验一下 — 部署成本远比你想象的低，收益远比你想象的高。

饮墨