Istio是由Google、IBM、Lyft聯合開發的開源項目，它是一款微服務管理框架，也被稱為第二代微服務Service Mesh代表。Istio的架構思想類似軟件定義網絡，近年來隨著技術的不斷發展，Istio因其輕量級、服務網格管理理念、兼容各大容器編排平臺等優勢在近兩年脫穎而出。本期智匯華云將為大家詳細描述 Istio 中證書簽發和管理的整個流程以及涉及到的組件。
一、概述
本文會詳細描述 Istio 中證書簽發和管理的整個流程以及涉及到的組件，假設讀者已經有一些技術儲備，對于 Istio 中的基本概念和使用比較熟悉。
上圖是 Istio 內部在簽發證書時的流程和相關的組件。
在Istiod內部有一個名為CA Server服務的組件，用來提供證書簽名的服務。
上圖中Pod A是用戶的負載，伴隨著Pod A是Istio注入的sidecar，啟動的主進程被稱為Pilot Agent，它核心的功能是啟動Envoy進程來劫持并管理Pod A的進出口流量，除此之外，在Pilot Agent還有一個名為SDS Server的組件，用來生成私鑰和證書簽名請求文件并向CA Server發起證書簽名請求。
CA Server和SDS Server通信時，需要驗證對方的身份，這時雙方都需要有一個公共的CA根證書，這個根證書最初由CA Server在啟動時創建，并存儲于Kubernetes一個名為istio-ca-root-cert的ConfigMap對象中。這個ConfigMap會在注入sidecar時，掛載到sidecar的/var/run/secrets/istio目錄中，隨后當SDS Server與CA Server交互時會讀取這個根證書，并用它創建client然后進行通信。
主要的流程如下：
1. 當Envoy進程在與其它Envoy進程交互時，發現需要進行TLS認證，它會從靜態配置文件或者動態配置服務器獲取證書的名稱等相關信息，這時Envoy進程就會通過SDS API向Pilot Agent中的SDS Server發起請求獲取證書。
2. SDS Server收到請求后，會首先讀取本地的ServiceAccount Token，路徑為/var/run/secrets/kubernetes.io/serviceaccount/token，然后從token中解析出namespace和ServiceAccount等信息，再用這些信息生成私鑰和證書簽名請求文件。接下來使用證書簽名請求文件作為參數，向Istiod發起申請證書簽名的請求。
3. Istiod中的CA Server收到請求后會對其中的憑證進行驗證，通過后會對根據請求對證書進行簽名、生成證書，并將簽名后的數字證書發送給SDS Server。
4. SDS Server將私鑰和從CA Server處獲得的證書一起通過SDS API發送給Envoy。
5. 以上過程會周期性地重復執行以便實現證書的輪換。
二、CA Server
Istio內部的CA Server用來提供證書簽名服務。內部會管理4個證書，都會掛載到/etc/cacerts/目錄下。
ca證書用于給集群中的工作負載進行簽名，即對Pilog Agent發起的CSR請求進行簽名。
ca證書和ca私鑰必須由根證書簽名。
ca證書鏈是ca證書與根證書之間的信任鏈。
這些證書有兩種方式來創建：
1. 自動生成，這種被稱為自簽名證書，這是默認的方式。
2. 用戶手動創建，即手動插入已存在的CA證書?？梢栽诓渴餓stiod前使用已存在的證書在istio-system中創建名為cacerts的secret，然后istio部署的時候會自動使用這個secret中的證書，具體可以參考Istio官方手冊 Plugging in existing CA Certificates。
有2個函數可以用來處理Pilot Agent發送過來的CSR請求。CreateCertificate()和HandleCSR()，其中第二個被標記為過時的。
CA Server中涉及到了很多相關的Kubernetes資源，現整理如下：
istio-ca-secret secret
位于istio-system中，用來持久化保存自簽名的ca私鑰和ca證書，其它字段都為空，只由Istiod使用，與Pilot Agent沒有關系。
istio-ca-root-cert configmap
每個namespace中都會有一個，用于保存根證書，會掛載到Pilot Agent的/var/run/secrets/istio目錄。
istio-security configmap
位于istio-system中，用來保存根證書。之前使用在nodeagent中，目前nodeagent已經集成到Pilot Agent中，根證書改為從istio-ca-root-cert configmap中獲取，目前代碼有注釋說明保留這個只是為了向前兼容，代碼中并沒有實際使用，以后會從代碼中完全移除。
cacerts secret
會掛載到Istiod的/etc/cacerts目錄，用戶可以手動通過現有證書創建這個secret，然后再部署Istio，這樣Istio就可以使用用戶指定的證書。
三、SDS Server
Pilot Agent中的SDS Server與Istiod內部的CA Server進行通信時，雙方都需要有一個根證書，根據配置的不同，這個根證書有幾種不同的獲取方式，對應的類型名稱為分別為istiod、kubernetes和custom。
下面來看一下注入的sidecar的模板文件。
可以看出在部署的時候是通過pilotCertProvider這個參數來控制的，默認值是istiod，在模板文件中會將這個參數的值設置到環境變量PILOT_CERT_PROVIDER中。當這個值是istiod的情況下，會將istio-ca-root-cert這個configmap掛載到/var/run/secrets/istio目錄中。
四、數據面證書
數據面證書是指Envoy與Envoy通信時需要的證書，這些證書是Envoy通過向Pilot Agent中的SDS Server發起SDS請求獲取的，而SDS Server內部獲取這些證書的方式其實有兩種：
1. SDS Server內部生成私鑰和證書簽名請求文件，然后再向Istiod內部的CA Server發起簽名請求，最后將簽名后的證書和私鑰一起發送給Envoy。這就是前文中一直提到的情況，也是默認值。
2. SDS Server讀取掛載的靜態證書文件。下面來看一下注入的sidecar的模板文件：
如果是這種手動插入證書的方式，則SDS Server會將用戶配置的證書直接返回給Envoy，而不是像前一種情況那樣本地生成私鑰和證書簽名請求然后向CA Server申請簽名。
五、控制面認證
Istiod中的CA Server和Pilot Agent中的SDS Server通信時，需要互相認證對方的身份。
SDS Server對CA Server認證的方式是標準的TLS認證，即CA Server啟動時會配置相應的證書，在交互前進行認證時，會將證書發送給SDS Server，后者對其進行驗證。
CA Server對SDS Server的認證有不止一種方式。
第一種方式使用客戶端證書認證進行認證，實際上這時并不會進行真正的認證，只是在當前已經通過證書認證的前提下，從證書中提取出一些對象來供后續使用。
另外需要注意的是這些認證方式如果啟用多個的話，只要其中有一個認證通過，就會被認為是總體認證通過。
六、參考
https://github.com/istio/istio/
