保护 Istio 服务网格

cert-manager 可以使用项目 istio-csr 与 Istio 集成。istio-csr 将部署一个代理，负责接收 Istio 网格中所有成员的证书签名请求，并通过 cert-manager 对其进行签名。

istio-csr 是一种代理，允许使用 cert-manager 来保护 Istio 工作负载和控制平面组件。

使用 cert-manager 发行者签署、交付和续订促进 mTLS 的证书 - 包括集群间和集群内。

安装

请参阅安装指南，了解如何在新的 kind 集群中设置 istio-csr。

遵循该指南是了解 istio-csr 实践的最佳方式。

低级细节（适用于有经验的 Istio 用户）

⚠️ 如果你只是想尝试 istio-csr，安装指南是更好的选择！

运行 istio-csr 需要几个步骤和先决条件：

一个没有安装 Istio 的集群
cert-manager 安装在集群中
一个 Issuer 或 ClusterIssuer，用于颁发 Istio 证书
istio-csr 已安装（可能通过 helm）
Istio 安装，并需要一些自定义配置，例如使用仓库中的示例配置。

为什么需要自定义 Istio 安装清单？

如果你查看示例 Istio 安装清单的内容，你会发现几个重要的自定义配置选项。

所需的更改包括将 ENABLE_CA_SERVER 设置为 false，并设置 Istio 将从中请求证书的 caAddress；替换 CA 服务器是 istio-csr 的主要目的！

挂载和静态指定根 CA 也是一个重要的推荐步骤。如果没有手动指定的根 CA，istio-csr 会默认尝试自动发现根 CA，这在理论上可能会导致签名者劫持攻击，例如，如果签名者的令牌被盗（例如 cert-manager 控制器的令牌）。

Issuer 或 ClusterIssuer？

除非你确定需要一个 ClusterIssuer，否则我们建议从 Issuer 开始，因为更容易理解 Issuer 的访问控制；它们是在命名空间中，因此在范围上自然更有限。

也就是说，如果你将整个 Kubernetes 集群视为一个信任域，那么 ClusterIssuer 将更加自然地适合。最佳选择将取决于你的具体情况。

我们的安装指南使用了 Issuer。

哪个 Issuer 类型？

无论你选择使用 Issuer 还是 ClusterIssuer，你还需要选择你想要的 Issuer 类型，例如

关键要求是可以将任意值放入 subjectAltName (SAN) X.509 扩展，因为 Istio 会将 SPIFFE ID 放置在那里。

这意味着 ACME Issuer 将无法工作 - 由 Let's Encrypt 等颁发的公开可信证书不允许在 SAN 中放置任意条目，这是出于非常好的理由。

如果你已经在使用 HashiCorp Vault，那么 Vault Issuer 是一个显而易见的选择。如果你想完全控制自己的 PKI，我们建议使用 CA Issuer。最终的选择权在你手中。

在 Istio 之后安装 istio-csr

这是不受支持的，因为这样做非常难以安全地完成。在 Istio 之后安装 istio-csr 很可能无法做到没有停机时间，因为在 Istio 之后安装 istio-csr 需要一段所有 Istio sidecar 都信任旧的 Istio 管理的 CA 和新的 cert-manager 控制的 CA 的时间段。

istio-csr 如何工作？

istio-csr 实现 gRPC Istio 证书服务，该服务验证、授权并签署来自 Istio 工作负载的传入证书签名请求，将所有证书处理路由到集群中安装的 cert-manager。

这与典型安装中的 istiod 行为无缝匹配，同时允许通过 cert-manager 管理证书。