老范的自言自语 Walter's Solo

teleport 中 tbot 与 teleport cluster 的安全通信

January 26, 2025 by walter

1. 证书签名过程概述

当 tbot 请求证书时，它与 Teleport 集群的 Auth Service 交互：

1. 私钥生成：

   • tbot 本地生成自己的私钥和公钥（通常使用 Elliptic Curve 或 RSA 算法）。
   • 这对密钥仅存储在 tbot 的环境中，私钥不会发送到 Teleport 集群。

2. CSR（Certificate Signing Request）生成：

   • tbot 使用生成的公钥创建一个 CSR（证书签名请求），并将其发送到 Teleport 集群的 Auth Service。
   • CSR 包含：
     • 公钥
     • 证书用途（如 SSH、Kubernetes、数据库等）
     • tbot 的身份信息（例如角色、用户名等）

3. CA 签名：

   • Teleport 集群的 Auth Service 验证 tbot 的身份（基于 token 或已有证书）。
   • 一旦认证通过，Auth Service 使用 Teleport 集群的 CA 私钥签署 tbot 的公钥。
   • 签名生成后，返回一个短期有效的证书给 tbot。

4. 证书使用：

   • tbot 将证书与自己的私钥组合起来，用于身份认证和通信。

2. 证书签名的责任归属

• tbot 的私钥：

  • 由 tbot 本地生成，并用于与生成的证书配对。
  • 私钥仅用于证明 tbot 对证书的控制权，整个签名过程与私钥无关。

• Teleport 集群的 CA 私钥：

  • Teleport 的 Auth Service 使用集群的 CA 私钥对 tbot 的公钥进行签名。
  • 这确保了证书受 Teleport 集群的信任链保护。

3. 为什么不使用 tbot 的私钥签名？

tbot 的私钥不会用来签名证书，因为：

1. 信任模型：

   • Teleport 使用集中化的 CA 来管理信任链，只有集群的 CA 才能发放可信证书。
   • 如果 tbot 用自己的私钥签名证书，其他组件无法验证该证书是否可信。

2. 证书信任链：

   • 所有组件（如 Teleport 的节点和代理）都信任集群的 CA。
   • 如果由 tbot 自签证书（self-signed certificate），其他组件将无法信任这些证书。

3. 安全性和权限控制：

   • 通过 CA 统一管理签名权限，可以集中控制和撤销证书，而不依赖于每个独立的 tbot 实例。

4. 短期证书的轮换机制

• Teleport 集群会签发短期有效的证书，通常有效期为几小时。
• tbot 会定期与 Auth Service 通信，在证书即将过期时请求新证书。
• 整个轮换过程与初次签名类似，由 Teleport 的 CA 签发新证书。

5. 验证机制

• 当 tbot 使用证书与其他组件通信时，对方会验证：
  1. 证书是否由集群的 CA 签名。
  2. 证书是否有效（未过期，且没有被撤销）。
  3. 证书中的身份信息（如角色）是否匹配请求的权限。

总结：
tbot 的证书是由 Teleport 集群的 CA 使用其私钥签名的，而不是用 tbot 的私钥。tbot 本地生成私钥和公钥后，通过 CSR 请求由 Teleport 集群完成签名，确保整个系统的信任链安全且集中化管理。

Comments |0|