1. 为什么轻量级堡垒机值得认真对待很多中小团队在运维安全这件事上都有一个共同的尴尬知道应该上堡垒机但一看商业方案的价格和部署复杂度就退缩了。一台像样的商业堡垒机动辄几万到几十万的授权费用还要配套独立的硬件服务器、数据库、存储部署周期动辄以周计算。对于只有几台到几十台主机的团队来说这明显是杀鸡用牛刀。但另一方面运维安全的现实问题又摆在眼前服务器密码在团队里传来传去谁在什么时候登录了哪台机器、执行了什么命令事后完全查不到。一旦出现误操作或者内部人员的不当行为根本没有追溯依据。更常见的情况是离职员工手里还留着几台机器的密码交接全靠自觉。Teleport 这个开源项目就是冲着这个痛点来的。它是一个用 Go 语言编写的轻量级堡垒机核心定位是“让安全的远程访问变得简单”。和传统堡垒机不同Teleport 不需要你改变现有的网络架构不需要在每台目标主机上装 Agent它通过证书体系来管理访问权限部署起来非常轻。整个服务端就是一个二进制文件配置文件用 YAML 写几分钟就能跑起来。这篇文章要聊的是 Teleport 在实际企业环境中的落地用法重点覆盖 Linux 和 Windows 主机的统一管理。我会从架构选型、证书体系、节点接入、权限控制、会话审计这几个维度展开把我在实际部署中踩过的坑和总结出来的经验都摊开讲。适合的读者是有一定 Linux 基础、负责团队运维安全、想用开源方案解决实际问题的工程师。如果你之前没接触过堡垒机也不用担心我会把每个概念都拆开讲清楚。2. Teleport 的核心架构与选型逻辑2.1 为什么选 Teleport 而不是其他开源方案开源堡垒机这个领域能打的选手其实不多。常见的几个选择各有各的问题。有的方案是基于 Web 终端的本质上是一个网页版的 SSH 客户端审计能力很弱只能录屏没法做细粒度的命令控制。有的方案需要在每台目标主机上装 Agent运维成本一下子就上去了尤其是 Windows 主机Agent 的兼容性和稳定性经常出问题。还有的方案依赖特定的数据库和中间件部署复杂度直逼商业产品。Teleport 的设计思路和它们都不一样。它的核心是一个证书颁发机构CA所有对目标主机的访问都必须经过 Teleport 代理代理在转发流量的同时完成身份验证和会话记录。这个架构的好处是目标主机不需要装任何 Teleport 的组件只需要信任 Teleport 的 CA 证书就行。对于 Linux 主机这意味着只需要在 sshd 配置里加一行 TrustedUserCAKeys对于 Windows 主机只需要把 CA 证书导入到系统的受信任根证书存储里。另一个关键优势是 Teleport 的协议支持。它原生支持 SSH、RDP、Kubernetes API、数据库协议MySQL、PostgreSQL、MongoDB 等这意味着你可以用同一套权限体系管理不同类型的资源。对于同时有 Linux 和 Windows 主机的环境来说这一点非常实用。你不需要为 Linux 和 Windows 分别部署两套堡垒机一套 Teleport 就能覆盖。还有一个容易被忽略的点是 Teleport 的客户端体验。它提供了 tsh 命令行工具用法和原生 ssh 几乎一样学习成本极低。同时也支持通过 Web 浏览器访问对于需要临时登录或者不方便装客户端的场景很方便。Web 终端的功能完整度很高支持复制粘贴、窗口调整、会话共享等。2.2 Teleport 的组件构成与数据流Teleport 的部署架构里有两个核心组件Proxy Service 和 Auth Service。在小型部署中这两个服务通常跑在同一台机器上统称为 Teleport 服务端。Auth Service 负责证书签发、用户认证、权限校验和会话记录存储Proxy Service 负责对外提供接入点包括 SSH 代理、Web 端口、RDP 代理等。数据流是这样的用户通过 tsh 或者浏览器发起连接请求请求先到 Proxy Service。Proxy 把请求转发给 Auth Service 做身份验证Auth 验证通过后签发一个短期的证书给用户。用户拿着这个证书去连接目标主机目标主机上的 sshd 或者 RDP 服务验证证书是否由受信任的 CA 签发。验证通过后连接建立同时 Proxy 会记录整个会话的过程。这个流程里有一个关键设计证书是有有效期的默认是 12 小时可以配置得更短。这意味着即使证书泄露攻击窗口也是有限的。而且证书里绑定了用户的身份和权限范围用户没法用自己的证书去访问没有授权的机器。这比传统的“用户名密码”或者“用户名SSH Key”的方式安全得多因为密码和 Key 是长期有效的一旦泄露就是永久性的风险。2.3 部署模式的选择单机 vs 高可用Teleport 支持两种部署模式单机模式和集群模式。单机模式就是 Auth 和 Proxy 跑在一台机器上数据存在本地或者外部数据库里。集群模式是把 Auth 和 Proxy 分开部署多个 Proxy 实例共享同一个 Auth 后端实现负载均衡和高可用。对于大多数中小团队来说单机模式完全够用。一台 2 核 4G 的云主机就能跑得很稳支持几百个并发会话没有问题。但如果你的环境对可用性要求很高比如堡垒机挂了会导致所有运维人员无法登录服务器那就需要考虑集群模式。集群模式的关键是 Auth 后端的选型Teleport 支持 etcd、DynamoDB、Firestore 等多种后端选择的时候要考虑你现有的基础设施和运维能力。我个人的建议是如果团队规模在 50 人以下主机数量在 200 台以内先用单机模式跑起来。等业务量上来了再考虑迁移到集群模式。Teleport 的配置迁移并不复杂主要是把 Auth 后端从本地存储换成外部数据库然后增加 Proxy 实例就行。3. 证书体系与身份认证的实操细节3.1 Teleport 的证书模型拆解Teleport 的证书体系和传统的 SSH Key 认证有本质区别。传统方式是每个用户生成一对密钥把公钥放到目标主机的 authorized_keys 文件里。这种方式的问题是密钥管理分散权限回收困难无法做细粒度的访问控制。Teleport 用的是短期证书 CA 信任的模型。整个体系里有几个关键角色User CA 负责签发用户证书Host CA 负责签发主机证书。当用户要连接一台主机时Teleport 会签发一个用户证书这个证书里包含了用户的身份信息、允许访问的主机列表、允许使用的登录名、证书有效期等。目标主机上的 sshd 配置了信任 User CA所以会接受这个证书。主机证书的作用是让 Teleport 集群能够验证目标主机的身份。当你在 Teleport 里注册一台新主机时主机会生成一个主机证书这个证书由 Host CA 签发。Teleport 集群通过验证主机证书来确认这台主机是合法的防止中间人攻击。这个模型的好处是权限控制非常灵活。你可以在 Teleport 的配置里定义角色每个角色可以指定允许访问的主机标签、允许使用的登录名、允许执行的命令等。当用户的证书签发时这些权限会被编码到证书里。目标主机上的 sshd 在验证证书时会检查证书里的权限是否允许当前的操作。3.2 用户认证方式的选型与配置Teleport 支持多种用户认证方式本地用户密码、GitHub OAuth、Google OAuth、SAML、OIDC 等。对于企业环境来说最常用的是对接现有的身份提供商比如 LDAP 或者 OIDC。如果团队规模很小用本地用户密码也能凑合。但这种方式的问题是没有集中管理用户离职后需要手动删除账号。对接 OIDC 的好处是用户身份由现有的身份系统管理离职后账号自动失效不需要在 Teleport 里单独维护。配置 OIDC 认证需要在 Teleport 的配置文件里添加 connector 配置。以通用的 OIDC 为例你需要提供 issuer URL、client ID、client secret、redirect URL 等信息。配置完成后用户登录时会跳转到身份提供商的页面进行认证认证通过后 Teleport 会签发证书。这里有一个实操中容易踩的坑redirect URL 的配置。Teleport 的 OIDC connector 需要配置一个回调地址这个地址必须是身份提供商允许的。如果配置错了登录时会报 redirect_uri_mismatch 错误。正确的做法是在身份提供商那边先注册应用拿到 client ID 和 secret然后把 Teleport 的回调地址填进去。回调地址的格式通常是https://proxy-host:port/v1/webapi/oidc/callback。3.3 角色与权限的细粒度控制Teleport 的权限模型是基于角色的访问控制RBAC。每个角色定义了一组权限用户可以被分配一个或多个角色。角色配置里最常用的几个字段是logins允许使用的登录名比如ubuntu、root、Administratornode_labels允许访问的主机标签用键值对表示比如env: productionrules允许执行的操作比如ssh、session、file_transfermax_session_ttl会话的最大有效期举个例子假设你有一个生产环境的角色只允许访问带有env: production标签的主机登录名限制为deploy会话有效期最长 4 小时。配置大概是这样kind: role version: v5 metadata: name: production-access spec: options: max_session_ttl: 4h forward_agent: false port_forwarding: false allow: logins: - deploy node_labels: env: production rules: - resources: [session] verbs: [read, list]这个配置里forward_agent设为 false 是出于安全考虑防止 SSH Agent 转发被滥用。port_forwarding设为 false 是禁止端口转发防止用户通过堡垒机建立隧道绕过审计。这些细节在实际安全加固中很重要默认配置往往比较宽松需要根据实际情况收紧。4. Linux 与 Windows 主机的接入实操4.1 Linux 主机接入的完整流程Linux 主机的接入相对简单核心步骤只有三步安装 Teleport 节点服务、生成加入令牌、启动服务。首先在目标主机上安装 Teleport。官方提供了二进制包和包管理器的安装方式。以 Debian 系为例可以用 apt 安装curl -fsSL https://apt.releases.teleport.dev/gpg \ -o /usr/share/keyrings/teleport-archive-keyring.asc echo deb [signed-by/usr/share/keyrings/teleport-archive-keyring.asc] \ https://apt.releases.teleport.dev/debian $(lsb_release -cs) stable/v12 \ | tee /etc/apt/sources.list.d/teleport.list apt update apt install teleport安装完成后需要生成一个加入令牌。这个令牌在 Teleport 服务端生成用来授权节点加入集群tctl tokens add --typenode --ttl1h生成的令牌是一串字符串把它复制到目标主机上然后启动 Teleport 服务teleport node start --tokentoken --auth-serverproxy-host:3025这里有几个关键参数需要说明。--auth-server指定的是 Teleport 的 Auth 服务地址默认端口是 3025。如果 Auth 和 Proxy 跑在同一台机器上填 Proxy 的地址就行。--token就是刚才生成的加入令牌。启动成功后Teleport 节点会向 Auth 服务注册自己并获取一个主机证书。你可以在 Teleport 的 Web 界面或者用tctl nodes ls命令查看已注册的节点。注意目标主机的 sshd 配置需要信任 Teleport 的 User CA。Teleport 节点服务在启动时会自动把 CA 证书写入/etc/ssh/trusted-user-ca-keys.pem但 sshd 的配置需要手动加上TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem这一行然后重启 sshd。这一步经常被遗漏导致证书验证失败。4.2 Windows 主机接入的关键差异Windows 主机的接入和 Linux 有本质区别。Linux 走的是 SSH 协议Windows 走的是 RDP 协议。Teleport 对 Windows 的支持是通过 RDP 代理实现的需要在 Windows 主机上安装 Teleport 的 Windows 版本并配置 RDP 相关的参数。Windows 版本的 Teleport 安装包是 MSI 格式安装过程是图形化的比较简单。安装完成后需要修改配置文件C:\Program Files\Teleport\teleport.yaml添加 RDP 服务的配置teleport: auth_token: token auth_servers: - proxy-host:3025 rdp: enabled: true listen_addr: 0.0.0.0:3389这里有一个关键点listen_addr配置的是 Teleport 的 RDP 监听地址不是 Windows 自带的 RDP 服务地址。Teleport 会接管 RDP 连接在验证用户身份后再转发给本地的 RDP 服务。所以 Windows 自带的 RDP 服务需要保持运行但防火墙规则要调整只允许 Teleport 访问本地的 3389 端口外部访问走 Teleport 的代理端口。另一个差异是证书的信任方式。Linux 是通过 sshd 的 TrustedUserCAKeys 配置来信任 CAWindows 是通过把 CA 证书导入到系统的受信任根证书存储。Teleport 在 Windows 上安装时会自动完成这一步但如果你用的是手动部署需要确认 CA 证书已经正确导入。实操心得Windows 主机的 RDP 会话录制比 Linux 的 SSH 会话录制更消耗资源因为 RDP 是图形协议录制的数据量更大。如果 Windows 主机比较多建议把 Teleport 的存储后端配置成外部数据库并且定期清理过期的会话记录。默认的本地存储在大规模使用下容易成为瓶颈。4.3 节点标签与动态分组Teleport 的节点标签是一个很实用的功能它允许你给每台主机打上标签然后在角色配置里通过标签来定义访问权限。标签是键值对的形式比如env: production、region: us-east、team: backend。给节点打标签有两种方式一种是在节点的配置文件里静态配置另一种是通过 Teleport 的 API 动态设置。静态配置的方式是在teleport.yaml里添加teleport: labels: env: production region: us-east动态设置的方式是用tctl命令tctl nodes update --labelsenvproduction,regionus-east node-id标签的价值在于权限控制的灵活性。比如你可以定义一个角色只允许访问env: staging的主机这样开发人员就只能访问测试环境碰不到生产环境。当新主机加入时只要打上正确的标签权限就自动生效了不需要修改角色配置。这里有一个容易忽略的细节标签的键和值都是大小写敏感的。env: Production和env: production会被视为不同的标签。在实际操作中建议统一用小写避免因为大小写不一致导致权限配置不生效。5. 会话审计与安全加固的实战经验5.1 会话录制的原理与存储配置Teleport 的会话录制是它的核心功能之一。当用户通过 Teleport 连接目标主机时所有的输入输出都会被记录下来。对于 SSH 会话录制的是终端流数据对于 RDP 会话录制的是图形界面的变化。录制的数据默认存在 Teleport 服务端的本地文件系统里路径是/var/lib/teleport/log。每个会话生成一个文件文件名包含会话 ID 和时间戳。这些文件可以用tsh play命令回放也可以在 Web 界面里直接查看。本地存储的问题是不方便集中管理和长期保存。如果 Teleport 服务端挂了录制数据可能丢失。对于企业环境建议把录制数据存到外部对象存储比如 S3 兼容的存储服务。Teleport 支持配置 S3 作为审计日志的后端teleport: storage: type: s3 region: us-east-1 bucket: teleport-audit-logs access_key: access-key secret_key: secret-key配置 S3 存储后会话录制数据会自动上传到指定的 bucket。这样做的好处是数据持久性有保障而且可以配合生命周期策略做自动归档和清理。注意S3 存储的配置里access key 和 secret key 是敏感信息不要直接写在配置文件里。建议用环境变量或者 IAM 角色来授权。如果必须写在配置文件里要确保配置文件的权限是 600只有 root 可读。5.2 命令审计与实时监控除了会话录制Teleport 还支持命令级别的审计。对于 SSH 会话Teleport 可以记录用户执行的每一条命令包括命令的内容、执行时间、退出码等。这些信息会写入审计日志可以通过tctl命令或者 Web 界面查询。命令审计的配置需要在角色的rules里添加exec权限rules: - resources: [exec] verbs: [read, list]启用命令审计后你可以用tctl audit ls命令查看审计事件也可以用tctl audit search按条件搜索。比如查找某个用户在某个时间段内执行的所有命令tctl audit search --useralice --start2024-01-01 --end2024-01-31实时监控方面Teleport 支持把审计事件推送到外部系统比如 Slack、PagerDuty、Elasticsearch 等。配置方式是在 Teleport 的配置文件里添加event_handler配置。比如推送到 Slackteleport: event_handlers: - type: slack webhook_url: https://hooks.slack.com/services/xxx events: - session.start - session.end - user.login这样配置后每当有用户登录或者会话开始/结束Slack 频道里就会收到通知。对于安全敏感的环境这个功能很实用可以及时发现异常登录行为。5.3 安全加固的实操清单Teleport 的默认配置偏向易用性安全加固需要手动调整。以下是我在实际部署中总结的加固清单加固项默认值建议值说明会话有效期12h4h缩短证书有效期降低泄露风险端口转发允许禁止防止用户通过堡垒机建立隧道Agent 转发允许禁止防止 SSH Agent 被滥用密码认证允许禁止强制使用证书认证会话录制开启开启确保所有会话都有记录审计日志存储本地外部存储防止数据丢失登录名限制无限制白名单只允许必要的登录名这些配置大部分可以在角色的options里设置。比如禁止端口转发和 Agent 转发options: forward_agent: false port_forwarding: false max_session_ttl: 4h禁止密码认证需要在 Auth 服务的配置里设置auth_service: authentication: type: local second_factor: off passwordless: truepasswordless: true会禁用密码登录只允许证书认证。这个配置在初始设置时要注意确保你已经配置好了其他认证方式否则可能会把自己锁在外面。6. 常见问题排查与避坑指南6.1 节点注册失败的排查思路节点注册失败是最常见的问题之一。症状是目标主机上的 Teleport 服务启动后在 Teleport 服务端看不到节点。排查的时候按以下顺序检查首先确认网络连通性。目标主机能否访问 Teleport 的 Auth 服务端口默认 3025用telnet或者nc测试一下。如果网络不通检查防火墙规则和安全组配置。其次检查令牌是否有效。令牌默认有效期是 1 小时如果生成后过了很久才用可能已经过期了。用tctl tokens ls查看令牌状态过期的令牌需要重新生成。然后检查配置文件。teleport.yaml里的auth_servers地址是否正确auth_token是否和生成的令牌一致配置文件的缩进是否正确YAML 对缩进很敏感一个空格错了就可能导致解析失败。最后看日志。Teleport 的日志在/var/log/teleport.log启动失败的原因通常会在这里显示。常见的错误包括CA 证书验证失败、令牌无效、端口被占用等。实操心得如果节点注册成功但连接时提示证书验证失败大概率是 sshd 的 TrustedUserCAKeys 配置没生效。检查/etc/ssh/sshd_config里是否有TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem然后确认这个文件存在且内容正确。改完配置后记得systemctl restart sshd。6.2 RDP 连接问题的典型场景Windows 主机的 RDP 连接问题比 Linux 的 SSH 更复杂因为涉及图形协议和 Windows 的认证机制。常见的几个问题第一个是 RDP 端口冲突。Teleport 的 RDP 代理默认监听 3389 端口但 Windows 自带的 RDP 服务也监听 3389。如果两个服务跑在同一台机器上会冲突。解决办法是把 Windows 自带的 RDP 服务改到其他端口或者把 Teleport 的 RDP 监听端口改成别的。第二个是证书信任问题。Windows 的 RDP 客户端在连接时会验证服务端证书。如果 Teleport 的 RDP 代理用的是自签名证书客户端会弹出警告。解决办法是把 Teleport 的 CA 证书导入到 Windows 的受信任根证书存储或者配置 Teleport 使用受信任的证书。第三个是登录名格式问题。Windows 的登录名通常需要带域名前缀比如DOMAIN\username或者usernamedomain.com。在 Teleport 的角色配置里logins字段需要配置成 Windows 能识别的格式。如果配置成Administrator连接时可能会提示用户名或密码错误。6.3 性能调优与容量规划Teleport 的性能瓶颈通常出现在两个地方Auth 服务的证书签发和会话录制的存储写入。对于中小规模部署默认配置基本够用。但如果节点数量超过 200 台或者并发会话超过 100 个就需要考虑调优。Auth 服务的调优主要是增加缓存和调整数据库连接池。Teleport 支持配置多个 Auth 实例做负载均衡但需要共享同一个存储后端。存储后端的选型上etcd 适合小规模DynamoDB 和 Firestore 适合大规模。会话录制的性能调优主要是调整缓冲区大小和上传并发数。如果用的是 S3 存储可以配置upload_concurrency参数来控制并发上传的数量。默认值是 5如果网络带宽充足可以调到 10 或更高。容量规划方面一个参考数据是每 100 台节点大约需要 1 核 CPU 和 1GB 内存。会话录制的存储需求取决于会话的频率和时长一个典型的 SSH 会话录制文件大约 10KB 到 100KBRDP 会话录制文件可能达到几 MB。按每天 100 个会话计算一年的存储需求大约在 10GB 到 100GB 之间。6.4 常见问题速查表问题现象可能原因排查方法解决方案节点注册失败网络不通telnet 测试端口检查防火墙和安全组节点注册失败令牌过期tctl tokens ls重新生成令牌连接提示证书错误CA 未信任检查 sshd 配置添加 TrustedUserCAKeysRDP 连接失败端口冲突netstat 查看端口修改监听端口RDP 登录失败登录名格式错误查看角色配置使用 DOMAIN\user 格式会话录制丢失存储空间不足df -h 查看磁盘清理旧日志或扩容性能下降并发过高查看 CPU 和内存增加 Auth 实例或调优7. 从单机到集群的扩展路径7.1 什么时候需要考虑集群部署单机部署的瓶颈通常出现在三个信号出现时第一Teleport 服务端的 CPU 或内存持续超过 70%第二会话录制的写入延迟明显增加回放时经常卡顿第三需要保证堡垒机的高可用不能接受单点故障。这三个信号里前两个是性能问题第三个是可用性问题。性能问题可以通过垂直扩容升级服务器配置暂时缓解但可用性问题只能通过集群部署解决。对于运维安全这种关键基础设施我个人的建议是如果团队对运维中断的容忍度很低一开始就上集群模式避免后期迁移的麻烦。集群部署的核心是把 Auth 服务和 Proxy 服务分开。Auth 服务通常部署 2 到 3 个实例共享同一个存储后端。Proxy 服务可以部署多个实例前面挂负载均衡。客户端连接时通过负载均衡访问 ProxyProxy 再把请求转发给 Auth。7.2 存储后端的迁移实操从单机迁移到集群最关键的一步是存储后端的迁移。单机模式下Teleport 默认用本地文件系统存储数据。迁移到集群模式需要把存储换成外部数据库。Teleport 支持多种存储后端选择的时候要考虑几个因素现有基础设施、运维成本、性能要求。如果团队已经在用 etcd那用 etcd 做存储后端是最自然的选择。如果用的是云服务DynamoDB 或 Firestore 的托管服务可以省去运维成本。迁移的步骤大致是先在新环境部署好外部存储然后配置 Teleport 使用外部存储最后把本地存储的数据导入到外部存储。Teleport 提供了tctl命令来做数据导出和导入# 从本地存储导出数据 tctl export --outputbackup.tar # 导入到新的存储后端 tctl import --inputbackup.tar迁移过程中要注意迁移期间最好停止写入操作避免数据不一致。如果无法停止服务可以考虑双写方案但配置比较复杂一般不建议。7.3 多数据中心部署的注意事项如果团队有多个数据中心或者多个云区域Teleport 支持多数据中心部署。核心思路是在每个数据中心部署一套 Proxy共享同一个 Auth 集群。这样用户连接时可以选择最近的 Proxy减少网络延迟。多数据中心部署的关键是 Auth 集群的跨区域同步。如果 Auth 后端用的是 etcd需要配置跨区域的 etcd 集群这对网络延迟和稳定性要求很高。如果用的是 DynamoDB 或 Firestore它们本身是全球分布的服务跨区域同步是自动的配置起来简单很多。另一个需要注意的是证书的信任范围。在多数据中心部署中所有数据中心的节点都需要信任同一个 User CA。这意味着 CA 的私钥需要安全地共享给所有 Auth 实例。Teleport 支持 CA 轮换可以定期更换 CA 证书降低私钥泄露的风险。实操心得多数据中心部署时建议给每个数据中心的节点打上区域标签比如region: dc1、region: dc2。然后在角色配置里限制用户只能访问特定区域的节点。这样即使某个区域的 Proxy 被攻破攻击者也无法访问其他区域的节点。8. 个人实操体会与后续扩展方向Teleport 这个项目我从早期版本就开始用一路跟到现在的 v12、v13最大的感受是它在“简单”和“安全”之间找到了一个很好的平衡点。很多安全工具的问题是太复杂部署和维护成本高最后大家为了省事就绕过了。Teleport 的设计哲学是让安全的做法成为最方便的做法这一点在实际推广中非常重要。我在实际部署中踩过的最大的坑是证书有效期和时钟同步。Teleport 的证书验证依赖时间戳如果目标主机的时钟和 Teleport 服务端的时钟偏差太大证书验证会失败。这个问题在虚拟机环境里特别常见因为虚拟机的时钟容易漂移。解决办法是在所有节点上配置 NTP 同步确保时钟偏差在几秒以内。另一个体会是权限配置要遵循最小权限原则。刚开始用的时候为了方便给所有人都配了root登录名和所有节点的访问权限。后来发现这样风险很大一旦某个账号被盗攻击者可以访问所有机器。后来改成了按角色分配权限开发人员只能访问测试环境运维人员按职责划分生产环境的访问范围。虽然配置麻烦了一点但安全性提升很明显。后续扩展方向的话我建议关注几个点一是 Teleport 和 Kubernetes 的集成可以用同一套权限体系管理 K8s 集群的访问二是 Teleport 的数据库访问代理可以用它来管理 MySQL、PostgreSQL 等数据库的访问实现数据库操作的审计三是 Teleport 的 Terraform Provider可以用代码来管理 Teleport 的配置实现基础设施即代码。最后分享一个小技巧Teleport 的 Web 界面支持会话共享多个用户可以同时观看同一个会话。这个功能在故障排查和知识传递时特别有用。比如一个新同事遇到问题老同事可以通过会话共享直接看到他的操作过程实时指导比截图或者文字描述高效得多。配置方式是在角色里开启session_sharing权限然后在 Web 界面里点击“共享会话”按钮就行。
