Kubernetes 是编排现代云原生工作负载的事实标准。但是，它不提供开箱即用的安全通信。这意味着每个需要实施传输中加密以对其 Kubernetes 部署采用零信任安全态势的人都需要自己解决这个问题。
幸运的是，有很多易于理解的方法可以实现，在本文中，我们将介绍在 Kubernetes 中实现双向 TLS（mTLS）的三大最佳实践。
传输层安全性（SSL 的后继者）是部署最广泛的安全通信标准，在 HTTPS 中最为明显。TLS 非常适合在需要向客户端证明其身份的服务器之间建立既保密（防窃听）又真实（防篡改）的安全通信。但是，在双方都需要向对方证明身份的情况下（例如在 Kubernetes 应用程序中的微服务之间），TLS 是不够的。
这就是双向 TLS (mTLS) 的用武之地。mTLS 是 TLS，但双方在建立安全通信通道之前向对方证明自己的身份。这是 Kubernetes 中安全通信所需的必要部分。mTLS 提供：
要深入了解 mTLS 的工作原理，请参阅我们关于 mTLS 的文章。
困难的部分是为服务建立一个安全机制来向彼此证明它们的身份。
对于常规 TLS，过去很难管理向其客户端证明服务器身份的证书。随着 Let’s Encrypt 和 ACME 协议的出现，这变得容易多了。然而，在像 Kubernetes 这样的动态（并且主要是私有的）环境中管理服务身份和证书更加困难，因为有许多通常是短暂的服务需要强大的、可证明的身份，但实际上不能使用公共 ACME 服务。
推出自己的自动化证书管理系统是不切实际且有风险的。正确管理 mTLS 证书很困难，错误的后果很严重。您需要一种可信赖的、经过验证的方法来做到这一点；这就是服务网格的用武之地。
在微服务安全标准中，美国国家标准与技术研究院 (NIST) 建议使用服务网格作为专用基础设施层来提供核心网络安全功能。这些核心功能之一是支持 mTLS 的强大服务身份和证书管理。而且，Istio——使用最广泛的服务网格—— 为您提供开箱即用的 mTLS 支持。Istio 透明地提供基础设施 —— 包括安全命名、强大的服务身份和证书管理 —— 用于 Kubernetes 工作负载之间的安全通信以及与外界的连接。
如果您想详细了解 NIST 的微服务安全标准以及 Tetrate 如何帮助满足这些标准，请查看 Tetrate 的微服务联邦安全要求指南。
虽然 Istio 将为您实施 mTLS，但它默认使用自签名证书，因此您可以立即看到网格工作，只需最少的配置。这使得初始用户体验变得简单，但它并非不适合生产环境。NIST 的指南（NIST SP 800-204A，SM-DR12）是完全禁用生成自签名证书的能力。
如果不应该使用 Istio 的默认自签名证书，还有什么选择？简短的回答是，您应该 将 Istio 的信任根植于您现有的公钥基础设施 (PKI) 中。这将通过确保它们都具有相同的信任根来实现跨其他集群中的 Istio 部署的通信。观看我们关于 使用 Istio 的外部 CA 的视频，了解更多信息。
确切地说，您如何让 Istio 信任您现有的 PKI？Tetrate 的创始工程师和 NIST 微服务安全标准的合著者 Zack Butcher 在此处提供了所有详细信息。但是，简而言之，我们的建议是使用您组织的根证书颁发机构颁发的中间证书。这将：
有关如何自动化 Istio 证书颁发机构 (CA) 轮换的分步说明，请参阅我们关于 在大规模生产中自动化 Istio CA 轮换的文章。
如果您不熟悉服务网格和 Kubernetes 安全性，我们在 Tetrate Academy 提供一系列免费在线课程，可以让您快速了解 Istio 和 Envoy。
如果您正在寻找一种快速将 Istio 投入生产的方法，请查看 Tetrate Istio Distribution (TID)。TID 是 Tetrate 的强化、完全上游的 Istio 发行版，具有经过 FIPS 验证的构建和支持。这是开始使用 Istio 的好方法，因为您知道您有一个值得信赖的发行版，有一个支持您的专家团队，并且如果需要，还可以选择快速获得 FIPS 合规性。
一旦启动并运行 Istio，您可能需要更简单的方法来管理和保护您的服务，而不仅仅是 Istio 中可用的方法，这就是 Tetrate Service Bridge 的用武之地。您可以在这里详细了解 Tetrate Service Bridge 如何使服务网格更安全、更易于管理和弹性，或联系我们进行快速演示。
观看我们的视频：
最后更新于 2024/12/12