istio 的安裝設定調整 (4)

istio 在服務安全性的部分有個機制叫 mtls (mutual TLS) ，也就是服務之間的雙向 TLS 認證。

要打開 mtls 支援很簡單，把 values.yaml 裡的 mtls 設為 enable 就好，然後就可以用 istio 提供的工具 istioctl 驗證一下服務之間是否真的有 mtls

$ istioctl -n bookinfo authn tls-check sleep-7d457d69b5-zlt65 httpbin.bookinfo.svc.cluster.local
HOST:PORT                                   STATUS     SERVER     CLIENT     AUTHN POLICY     DESTINATION RULE
httpbin.bookinfo.svc.cluster.local:8000     OK         mTLS       mTLS       default/         default/istio-system 

httpbin 這個 sample app 我是裝在 bookinfo 這個 namespace ，這個要打完整的 FQDN 才能正確查詢。

如果沒使用 cert-manager ，TLS 使用的是 citadel 自行產生的憑證，也可以設定用其他憑證來取代 citadel 產生的，這部分可以參考官網。如果有使用 cert-manager，也就是使用 SDS 來取得憑證，那在 istio-proxy 這個 container 的 /etc/certs 就沒有 citadel 產生的憑證，這部分一樣可以參考官網。

enable mtls 很簡單，不過後續要考慮的問題就變多了。例如外部要來使用服務，但不支援 TLS 的時候，或是要使用到外部的服務，但是對方不支援 TLS 的時候，都會造成問題。

因為有可能並非整個 kubernetes cluster 都在 istio 的 service mesh 內，因此上面那段比較正確的講法應該是，"非 istio service" 與 "istio service" 之間的溝通。

當 "istio service" 往 "非 istio service" 請求時，可以設定一個 DestinationRule 來 disable 這條路徑的 mtls。事實上像 kuberentes apiserver 就沒有 istio 的 sidecar，所以預設會有一個 DestinationRule 是把通往 apiserver 的 mtls 給 disable ，這部分在官網有蠻清楚的說明。

對於已經上線的系統，可以透過 permissive mode來測試新增的 policy。
permissive mode 意思是該項 policy 並不會真的生效，但是可以透過適當的設定，使其在 telemetry 的 log 中觀察出區別。以上面官網提供的例子來說，在 rabcsampelog 這個 instance resource 裡，區分了 responseCode 和 permissiveResponseCode，前者是實際回應的 http response code，後者是 permissive 設定情況下應該會有的 http response code。也就是說，可以從 istio-telemetry 這個 pod 的 log 裡觀察 permissiveResponseCode ，就可以知道設定是否正確。

當 "非 istio service" 往 "istio service" 請求時，可以設定 service 同時接受 TLS 與明文的請求，也是使用 permissive mode。

從上面範例裡的 rbac-permissive-telemetry.yaml 這個檔案中，可以看到幾個新面孔的 CRD，像是 instance、handler 等，可以參考這篇的說明。

mtls 相關的部分，在官網寫得還算蠻清楚的，這部分我比較沒有實際動手操作確認，只有透過 istioctl 確認 mtls 運作正確，然後把幾個範例中的 yaml 掃過一遍，以及針對比較陌生的 CRD 稍微查了下資料。

為了 mtls ，把官網 tasks 裡的 security 項目整個掃過一遍，這是我始料未及的，裡面有很多我沒想到過的層面。雖然沒有整個流程實作過，但大致上有個初步的了解，希望日後若有機會運用到的話，不會手忙腳亂  QQ