該演示使用Envoy作為資料平面以及SPIRE和OPA作為控制平面在Kubernetese上構建Service Mesh。該演示是zlabjp / spiffejp-demo，其中新增了OPA。

• 使用Kubernetes 1.17.0
• 使用特使 1.12.2，SPIRE 0.9.0和OPA 0.15.1
• Envoy使用SPIRE作為SDS伺服器來獲取TLS證書
• Envoy使用OPA作為外部授權伺服器來檢查傳入請求是否被授權

Kubernetes叢集中正在執行四個服務。

• ec-web（spiffe://example.org/ec-web）
  • ec-web 僅接受包含“ ec-web-secret”值的自定義標頭“ X-Opa-Secret”的請求
• ec-backend（spiffe://example.org/ec-backend）
  • ec-backend可以只從訪問ec-web
• news-web（spiffe://example.org/news-web）
  • news-web 僅接受包含“ news-web-secret”值的自定義標頭“ X-Opa-Secret”的請求
• news-backend（spiffe://example.org/news-backend）
  • news-backend可以只從訪問news-web

架構：

具體架構如下；

Envoy，SPIRE Agent和OPA被啟用為每個pod的邊車。為了稍微解釋一下該功能，（ec | news）-web是Nginx，並且僅將從檢視器收到的請求代理到（ec | news）-backend，而（ec | news）-backend返回一個字串API。

簡要介紹從ec-web向ec-backend發出請求時的流程。

1. Envoy在啟動時從SPIRE Agent獲取mTLS所需的憑據，例如TLS客戶端證書
2. ec-web Pod中的應用程式向自己的Envoy發出請求，向ec-backend發出請求
3. 收到請求的Envoy向ec-backend的Envoy請求
4. 使用從SPIRE Agent獲得的憑據在ec-web和ec-backend Envoy之間通過mTLS進行相互身份驗證
5. 身份驗證成功後，ec-backend Envoy會向其OPA請求允許的請求。
6. OPA通過查詢預設策略和接收到的請求來執行授權處理
7. 如果授權成功，則ec-backend Envoy會將請求代理到其自己的App
8. ec-backend返回對ec-web的響應

上面是一個簡單的流程。

Envoy

Envoy是每個Pod之間通訊的中心人物，Envoy的重要功能是Secret Discovery Service（SDS），它是xDS API之一。

通過使用SDS，Envoy可以從SDS伺服器動態獲取TLS證書和mTLS通訊所需的金鑰。SPIRE代理充當了SDS伺服器，並且可以將TLS證書的管理（分發和輪換）委託給SPIRE。

接下來，關於外部授權，可以使用此功能將Envoy的網路過濾功能委託給另一個系統，如果確定不允許該請求，則通訊將關閉。 （對於HTTP，返回403）。這次，OPA將充當外部授權伺服器。

SPIRE

如Envoy部分所述，SPIRE的作用是管理（分發和輪換）TLS證書。SPIRE頒發的TLS證書包含SPIFFE ID（即工作負載的身份），因此，本次引入的Servicec Mesh使用基於SPIFFE ID的身份驗證和授權（通過Envoy中的mTLS和OPA中的SPIFFE ID進行相互身份驗證）。基於基礎的策略定義）是可能的。

*有關SPIRE的概述，請參閱開頭提到的幻燈片。

OPA

如Envoy部分所述，OPA的作用是代表Envoy的網路過濾功能。這次，將進行設定以充當HTTP篩選器的外部授權伺服器，並且基於HTTP請求所儲存的資訊來定義策略。當然，HTTP請求的資訊包括TLS證書，因此可以基於SPIFFE ID進行控制。

點選標題見Github.