idou老師帶你認識Istio13：Istio實現基礎認證策略
前言
微服務架構提供了更好的靈活性、可伸縮性以及服務複用的能力，但，微服務也有特殊的安全需求，Istio Security嘗試提供全面的安全解決方案。為了提供靈活的服務訪問控制，需要雙向 TLS 和細粒度的訪問策略。Istio 提供兩種型別的身份驗證：傳輸身份驗證和來源身份驗證。通過配置不同級別的認證策略，可以快速控制不同的安全訪問粒度。
典型的使用場景：
1.在未啟用雙向TLS的安裝好 Istio 的 Kubernetes 叢集中，需要快速啟用全網格雙向TLS；
2.網格內某些服務之間需要使用雙向TLS，可以將這些服務放入同一名稱空間並在名稱空間啟用雙向TLS；
3.當單個服務需要啟用TLS時，可以在配置策略中通過spec欄位指定；
認證策略是對服務收到的請求生效的，要在雙向 TLS 中指定客戶端認證策略，需要在DetinationRule 中設定 TLSSettings，每個認證策略需要和目的地規則共同生效。下面通過例項來演示在不同儲存範圍內配置傳輸身份認證策略的過程，來源身份驗證通過spec中的origins欄位指定。
環境準備：裝好istio的叢集，禁用全域性雙向TLS；Httpbin應用映象和sleep應用映象
1.建立名稱空間、部署應用
建立3個名稱空間：foo、bar、legacy，foo和bar中部署帶sidecar的httpbin應用和sleep應用，legacy中部署不帶sidecar的httpbin應用和sleep應用。
將sleep作為客戶端，httpbin作為服務端，驗證客戶端服務端可達性
2.驗證系統中目前不存在認證策略
可以看到在foo、bar和legacy名稱空間中沒有任何策略和規則
3.為網格中的所有服務啟用雙向TLS認證
配置網格認證策略：
配置目的地規則：
需要注意的是，網格範圍內的認證策略名稱必須是default，其它名稱的策略都會被拒絕和忽視，它的策略型別是MeshPolicy，不同於其它級別的策略型別
這些認證策略和目的地規則有效地配置了所有的sidecars，使服務在雙向TLS模式下收發請求。但是對不帶sidecar的服務並不適用。
可以看到上面有兩種連線不適用：從帶有 sidecar 的客戶端到不帶 sidecar 的服務端的連線以及從不帶 sidecar 的客戶端到帶有 sidecar 的服務端的連線。
① 為了修復從帶有 sidecar 的客戶端到不帶 sidecar 的服務端的連線，可以專門為這些服務端新增目的地規則來覆蓋 TLS 設定：
重新測試連線
當啟用全域性雙向 TLS 認證時，這種方法也可以用來配置 Kubernetes 的 API 伺服器。
② 從不帶 sidecar 的客戶端到帶有 sidecar 的服務端(工作在雙向 TLS 模式)的連線，唯一的選擇是從雙向 TLS 模式切換到 PERMISSIVE 模式，該模式允許服務端接收 HTTP 或（雙向） TLS 流量
從 sleep.legacy 到 httpbin.foo 的請求應當是成功的，但是到 httpbin.bar 的請求依然會失敗。
- 為一個名稱空間中的所有服務啟用雙向TLS
可以配置策略為每一個名稱空間單獨啟用雙向 TLS 而不必啟用全域性雙向 TLS：
注意：名稱空間範圍內的策略必須命名為 default，並且不限定任何特定的服務（沒有 targets 設定域）
新增相應的目的地規則：
測試連線：
由於當前配置的策略和目的地規則只對名稱空間foo有效，可以看到，只有從不帶 sidecar 的客戶端 (sleep.legacy) 到 httpbin.foo 的請求會失敗。
5.為單個服務啟用雙向TLS
你也可以為某個特定的服務設定認證策略和目的地規則。執行以下命令只為 httpbin.bar 服務新增一項策略。
配置目的地規則：
- 同時啟用名稱空間層級和服務層級
假設我們已經為名稱空間 foo 中所有的服務添加了啟用雙向 TLS 的名稱空間層級的策略並且觀察到從 sleep.legacy 到 httpbin.foo 的請求都失敗了（見上文）。現在專門為 httpbin 服務新增額外的策略來禁用雙向 TLS （peers 域留空）：
可以看到服務層級的策略覆蓋了名稱空間層級的策略，連線成功。
通過以上步驟，我們知道如何在不同層級配置認證策略和目的地規則。