这是一个测试功能。如果你在使用中遇到任何问题，请提供反馈并在 GitHub 上提交问题。
该功能尚未完全完成，请查看的详细路线图状态了解更多详情。
双向认证和 mTLS 背景
双向传输层安全性（mTLS）是一种机制，它确保了网络上两个实体之间交换的数据的真实性、完整性和机密性。
与传统的 TLS 不同，后者涉及单向认证过程，其中客户端验证服务器的身份，双向 TLS 通过要求客户端和服务器相互认证，增加了额外的安全层。
双向 TLS 的目的是为服务到服务的通信提供认证、机密性和完整性。
Cilium 中的双向认证
Cilium 的基于 mTLS 的双向认证支持，将双向认证握手带到常规连接的外部。
为了满足服务到服务认证和加密的大多数常见要求，用户必须启用加密。
注意
Cilium 的加密功能，WireGuard 透明加密 和 IPsec 透明加密，可以启用以自动在 Pod 之间创建和维护加密连接。
为了应对动态和异构环境中身份验证的挑战，双向认证需要一个安全的身份验证框架，用于分布式系统。
注意
要了解更多关于 Cilium 服务网格的双向认证架构，请阅读CFP。
身份管理
在 Cilium 当前的双向认证支持中，通过使用 SPIFFE（Secure Production Identity Framework for Everyone）提供身份管理。
SPIFFE 的好处
以下是 SPIFFE 提供的一些好处：
- 可信的身份发放：SPIFFE 提供了一个标准化的机制来发放和管理身份。它确保分布式系统中的每个服务都接收到唯一且可验证的身份，即使在服务可能频繁扩展或缩小的动态环境中。
- 身份认证：SPIFFE 允许服务通过认证来证明它们的身份。它确保服务可以通过提供关于其身份的可验证证据（如数字签名或加密证明）来展示其真实性和完整性。
- 动态和可扩展的环境：SPIFFE 应对动态环境中身份管理的挑战。它支持自动身份发放、轮换和撤销，这些在云原生架构中至关重要，因为服务可能会不断地部署、更新或退役。
Cilium 和 SPIFFE
SPIFFE 提供了一个 API 模型，允许工作负载从中央服务器请求身份。在我们的案例中，工作负载意味着与 Cilium 安全身份相同的东西 — 一组由标签集描述的 Pods。SPIFFE 身份是 URI 的一个子类，看起来像这样：spiffe://trust.domain/path/with/encoded/info。
SPIFFE 设置的两个主要部分是：
- 一个中央 SPIRE 服务器，形成信任域的根。
- 每个节点的 SPIRE 代理，首先从 SPIRE 服务器获得自己的身份，然后验证其节点上运行的工作负载的身份请求。
当一个工作负载想要获得其身份时，通常在启动时，它会使用 SPIFFE 工作负载 API 连接到本地 SPIRE 代理，并向代理描述自己。
SPIRE 代理然后检查工作负载是否真的是它所声称的那样，然后连接到 SPIRE 服务器并证明工作负载正在请求一个身份，并且该请求是有效的。
SPIRE 代理会检查许多关于工作负载的事情，比如该 Pod 是否真的在它来自的节点上运行，标签是否匹配等。
一旦 SPIRE 代理从 SPIRE 服务器请求了一个身份，它就会以 SVID (SPIFFE Verified Identity Document) 格式将其传回给工作负载。这份文档包括 X.509 版本的 TLS 密钥对。
在 SPIRE 的通常流程中，工作负载会从 SPIRE 服务器请求其自身的信息。在 Cilium 对 SPIFFE 的支持中，Cilium 代理获得一个公共的 SPIFFE 身份，并且可以代表其他工作负载请求身份。