保護 Istio 服務網格的安全

cert-manager 可以使用 istio-csr 專案與 Istio 整合。istio-csr 將部署一個代理程式，負責接收 Istio 網格所有成員的憑證簽署請求，並通過 cert-manager 簽署這些請求。

istio-csr 是一個代理程式，允許使用 cert-manager 保護 Istio 工作負載和控制平面組件的安全。

促進 mTLS（集群內部和集群之間）的憑證將使用 cert-manager 簽發者進行簽署、交付和更新。

安裝

請參閱安裝指南，以在新的 kind 集群中設定 istio-csr。

遵循該指南是了解 istio-csr 實際運作的最佳方式。

⚠️ 如果您只想試用 istio-csr，安裝指南會是更好的選擇！

執行 istio-csr 需要幾個步驟和先決條件，順序如下：

如果您查看範例 Istio 安裝資訊清單的內容，會發現一些重要的自訂設定選項。

所需的變更包括將 ENABLE_CA_SERVER 設定為 false，並設定 Istio 將從中請求憑證的 caAddress；取代 CA 伺服器是 istio-csr 的重點所在！

掛載和靜態指定根 CA 也是一個重要的建議步驟。如果沒有手動指定的根 CA，istio-csr 會預設為嘗試自動探索根 CA，這理論上可能導致簽署者劫持攻擊，例如如果簽署者的令牌被盜（例如 cert-manager 控制器的令牌）。

除非您知道您需要 ClusterIssuer，否則我們建議從 Issuer 開始，因為這樣更容易推論 Issuer 的存取控制；它們是命名空間的，因此範圍自然會受到一些限制。

也就是說，如果您將整個 Kubernetes 集群視為一個信任網域本身，那麼 ClusterIssuer 會是更自然的選擇。最佳選擇將取決於您的具體情況。

我們的安裝指南使用 Issuer。

無論您選擇使用 Issuer 還是 ClusterIssuer，您還需要選擇您想要的簽發者類型，例如

關鍵要求是可以在 subjectAltName (SAN) X.509 擴充中放置任意值，因為 Istio 會將 SPIFFE ID 放在那裡。

這表示 ACME 簽發者將無法運作 — 諸如 Let's Encrypt 等公開信任的憑證不允許在 SAN 中有任意條目，這是基於非常好的理由。

如果您已在使用 HashiCorp Vault，那麼 Vault 簽發者是一個顯而易見的選擇。如果您想完全控制自己的 PKI，我們建議使用 CA 簽發者。最終選擇取決於您。

這不受支援，因為安全地執行此操作非常困難。在 Istio 之後安裝 istio-csr 可能無法在不停機的情況下完成，因為第二次安裝 istio-csr 將需要一段時間，讓所有 Istio sidecar 同時信任舊的 Istio 管理的 CA 和新的 cert-manager 控制的 CA。

istio-csr 實作 gRPC Istio 憑證服務，該服務會對來自 Istio 工作負載的傳入憑證簽署請求進行驗證、授權和簽署，並將所有憑證處理路由至集群中安裝的 cert-manager。

這與典型安裝中 istiod 的行為無縫匹配，同時允許透過 cert-manager 進行憑證管理。