安全性常見問題

您可以使用身份驗證策略和目標規則，隨時更改服務的相互 TLS 設定。 請參閱任務了解更多詳細資訊。

身份驗證策略可以是網格範圍的（影響網格中的所有服務）、命名空間範圍的（影響同一命名空間中的所有服務），或是特定於服務的。您可以擁有策略或多個策略，以您想要的任何方式為叢集中的服務設定相互 TLS。

如果您安裝 Istio 時使用 values.global.proxy.privileged=true，您可以使用 tcpdump 來判斷加密狀態。另外，在 Kubernetes 1.23 及更高版本中，除了以特權模式安裝 Istio 之外，您可以使用 kubectl debug 在臨時容器中執行 tcpdump。請參閱Istio 相互 TLS 遷移以取得說明。

當啟用 STRICT 相互 TLS 時，非 Istio 工作負載無法與 Istio 服務通訊，因為它們將沒有有效的 Istio 用戶端憑證。

如果您需要允許這些客戶端，可以將相互 TLS 模式設定為 PERMISSIVE，允許純文字和相互 TLS。這可以針對個別工作負載或整個網格進行設定。

請參閱身份驗證策略以了解更多詳細資訊。

如果啟用相互 TLS，kubelet 的 HTTP 和 TCP 健康檢查將無法運作，除非進行修改，因為 kubelet 沒有 Istio 發出的憑證。

有幾種選項

1. 使用探針重寫將活性和就緒性請求直接重新導向到工作負載。請參閱探針重寫以獲取更多資訊。這在預設情況下啟用並建議使用。

2. 使用單獨的端口進行健康檢查，並且僅在常規服務端口上啟用相互 TLS。請參閱Istio 服務的健康檢查以獲取更多資訊。

3. 針對工作負載使用PERMISSIVE 模式，使其可以同時接受純文字和相互 TLS 流量。請注意，使用此選項不會強制執行相互 TLS。

對於在 Kubernetes 中執行的工作負載，其 Istio 憑證的生命週期預設為 24 小時。

可以通過自訂代理設定的 proxyMetadata 欄位來覆寫此設定。例如

proxyMetadata:
  SECRET_TTL: 48h

否。當在伺服器工作負載上使用 traffic.sidecar.istio.io/excludeInboundPorts 時，Istio 仍然會預設設定用戶端 Envoy 發送相互 TLS。若要更改此設定，您需要設定一個目標規則，並將相互 TLS 模式設定為 DISABLE，以使用戶端將純文字傳送到這些端口。

您可能會發現在安裝 Istio 後 MySQL 無法連線。這是因為 MySQL 是一種伺服器優先協定，可能會干擾 Istio 的協定偵測。特別是，使用 PERMISSIVE mTLS 模式可能會導致問題。您可能會看到類似於 ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 的錯誤訊息。

可以通過確保使用 STRICT 或 DISABLE 模式，或者設定所有用戶端發送 mTLS 來解決此問題。請參閱伺服器優先協定以獲取更多資訊。

是的。Istio 為網格中的 HTTP 和純 TCP 服務提供授權功能。了解更多。

按照安全 Ingress 流量任務中的指示，可以保護 Istio Ingress 只接受 TLS 流量。

是的，您可以。它在啟用和停用相互 TLS 的情況下都可以運作。