凡是產(chǎn)生連接關(guān)系，就必定帶來安全問題，人類社會如此，服務(wù)網(wǎng)格世界，亦是如此。

成都創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供鄲城網(wǎng)站建設(shè)、鄲城做網(wǎng)站、鄲城網(wǎng)站設(shè)計、鄲城網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、鄲城企業(yè)網(wǎng)站模板建站服務(wù)，十年鄲城做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

今天，我們就來談?wù)? Istio 第二主打功能 --- 保護服務(wù)。

那么，便引出 3 個問題：

l   Istio 憑什么保護服務(wù)？

l   Istio 具體 如何保護服務(wù)？

l   如何告訴Istio發(fā)揮保護能力？

1       Istio 憑什么保護服務(wù)？

將單體應(yīng)用程序分解為一個個服務(wù)，為大型軟件系統(tǒng)的開發(fā)和維護帶來了諸多好處，比如更好的靈活性、可伸縮性和可復(fù)用性。但這也帶來了一些安全問題：

l   為了抵御中間人攻擊，需要對流量進行加密

l   為了提供靈活的服務(wù)訪問控制，需要 mTLS （雙向的安全傳輸層協(xié)議）和細粒度的訪問策略

l   要審計誰在什么時候做了什么，需要審計工具

Istio 嘗試提供全面的安全解決方案來解決這 3 個問題。

如上圖所示，

Istio 安全的三大目標是：

l   默認安全（ Security by default ）：應(yīng)用程序代碼和基礎(chǔ)結(jié)構(gòu)，無需更改。

l   深度防御（ Defense in depth ）：與現(xiàn)有安全系統(tǒng)集成，提供多層防御。

l   零信任網(wǎng)絡(luò)（ Zero-trust network ）：在不受信任的網(wǎng)絡(luò)上，構(gòu)建安全解決方案。

為了實現(xiàn)這 3 個目標， Istio 安全功能提供了 4 大守護系統(tǒng)：

l   強大的身份（ Identity ）系統(tǒng)

l   健壯的策略（ Policy ）系統(tǒng)

l   認證，授權(quán)和審計（ AAA ： Authentication ， Authorization ， Accounting ）系統(tǒng)，用于保護服務(wù)和數(shù)據(jù)

l   透明的 TLS 加密（ Encryption ）系統(tǒng)。

就保護對象而言， Istio 安全系統(tǒng)可以抵御來自內(nèi)部或外部的威脅，這些威脅主要針對服務(wù)網(wǎng)格內(nèi)的端點（ Endpoints ），通信（ Communication ），平臺（ Platform ）和數(shù)據(jù)（ Data ）。

2       Istio 具體如何保護服務(wù)？

在安全方面， Istio 具備 3 個遠大的目標，配備了 4 大守護系統(tǒng)，那么它到底是通過怎樣的架構(gòu)實現(xiàn)這個目標的呢，又通過什么樣的安全基礎(chǔ)設(shè)施，和 kubernetes 配合呢？

2.1       Istio 安全架構(gòu)

如上圖 ，與 Istio 的 4 大守護系統(tǒng)相對應(yīng)， Istio 中涉及安全的組件有：

l   Pilot ：將授權(quán)策略和安全命名信息分發(fā)給代理

l   Proxy ：實現(xiàn)客戶端和服務(wù)端之間的安全通信

l   Citadel ：用于密鑰和證書管理

l   Mixer ：管理授權(quán)和審計

由此可見， Pilot 不僅負責流量規(guī)則和策略的分發(fā)，還負責安全相關(guān)策略的下發(fā)，有點像皇上的貼身太監(jiān)，負責宣讀圣旨； Proxy 有點像各州屬的州官，負責奉天承運； Citadel 有點像玉璽和虎符，負責鑒真去假； Mixer 有點像三省六部，負責授權(quán)審計。

2.2       兩個安全基本概念

2.2.1         Identity

身份（ Identity ）是幾乎所有安全基礎(chǔ)架構(gòu)的基本概念。在服務(wù)和服務(wù)的通信開始前，雙方必須用其身份信息交換憑證，以達到相互認證的目的。在客戶端，根據(jù)安全命名（ secure naming ）信息，檢查服務(wù)端的標識，以查看它是否是該服務(wù)的授權(quán)運行程序；在服務(wù)端，服務(wù)端可以根據(jù)授權(quán)策略（ authorization policies ）信息，確定客戶端可以訪問哪些數(shù)據(jù)，審計其在什么時間訪問了什么，拒絕未授權(quán)客戶端的訪問。

在 Istio 身份模型中， Istio 使用一流的服務(wù)標識來確定服務(wù)的身份。這為表示人類用戶，單個服務(wù)或一組服務(wù)提供了極大的靈活性和粒度。在沒有此類身份的平臺上， Istio 可以使用可以對服務(wù)實例進行分組的其他身份，例如服務(wù)名稱。

不同平臺上的 Istio 服務(wù)標識：

l   Kubernetes: Kubernetes 服務(wù)帳戶

l   GKE/GCE: 可以使用 GCP 服務(wù)帳戶

l   AWS: AWS IAM 用戶 / 角色 帳戶

l   On-premises (non-Kubernetes): 用戶帳戶，自定義服務(wù)帳戶，服務(wù)名稱， istio 服務(wù)帳戶或 GCP 服務(wù)帳戶。

做個類比，京東和天貓都有自己的一套非常成熟的服務(wù)賬戶系統(tǒng)，淘寶只需要復(fù)用天貓的賬戶系統(tǒng)即可，無需重新開發(fā)一套，這樣我們就可以用天貓的賬號，直接登錄淘寶。而 Istio 也更傾向于復(fù)用業(yè)界一流的服務(wù)賬戶系統(tǒng)，如 Kubernetes 和 AWS 的，但也可以自定義服務(wù)賬戶，并按需復(fù)用 Kubernetes 的賬戶系統(tǒng)。

2.2.2   PKI  

Istio PKI （ Public Key Infrastructure ）建立在 Istio Citadel 之上，可為每個工作負載提供安全且強大的工作負載標識。 Istio 使用 X.509 證書來攜帶 SPIFFE 格式的身份信息。 PKI 還可以大規(guī)模自動化地進行密鑰和證書輪換。

Istio 支持在 Kubernetes pod 和本地計算機上運行的服務(wù)。目前， Istio 為每個方案使用不同的證書密鑰配置機制，下面試舉例 Kubernetes 方案的配置過程：

1.          Citadel 監(jiān)視 Kubernetes apiserver ，為每個現(xiàn)有和新的服務(wù)帳戶創(chuàng)建 SPIFFE 證書和密鑰對。 Citadel 將證書和密鑰對存儲為 Kubernetes secrets 。

2.          創(chuàng)建 pod 時， Kubernetes 會根據(jù)其服務(wù)帳戶通過 Kubernetes secret volume 將證書和密鑰對掛載到 pod 。

3.          Citadel 監(jiān)視每個證書的生命周期，并通過重寫 Kubernetes secret 自動輪換證書。

4.          Pilot 生成安全命名信息，該信息定義了哪些服務(wù)帳戶可以運行某個服務(wù)。接著 Pilot 將安全命名信息傳遞給 Envoy 。

3       如何告訴 Istio 發(fā)揮保護能力？

如上一章節(jié)所言， Istio 基于控制面組件，引入了一流的服務(wù)賬戶系統(tǒng)，結(jié)合強大的 PKI ，實現(xiàn)了對服務(wù)網(wǎng)格的安全守護。同時， Istio 也開放了接口，讓我們可以進行精細化的配置，全方位滿足我們對服務(wù)的安全需求。

服務(wù)安全，總是離不開兩個具體過程：認證（ Authentication ）和鑒權(quán)（ Authorization ）。 Istio 通過 Policy 和 MeshPolicy 文件，實現(xiàn)對認證相關(guān)功能的定義；通過 RbacConfig 、 ServiceRole 和 ServiceRoleBinding 文件，實現(xiàn)對鑒權(quán)相關(guān)功能的啟用和定義。

讓我們舉個幾個通俗的例子來區(qū)分認證和鑒權(quán)：

進火車站需要提供身份證和火車票，身份證可以證明你就是你，這是認證；火車票可以證明你有權(quán)上那趟火車，這是授權(quán)。

又例如，你要訪問自己淘寶的購物車，需要先登錄，這是認證。你要訪問朋友的購物車，就需要他的允許，這是授權(quán)。

再例如，有經(jīng)驗的朋友能發(fā)現(xiàn)瀏覽器經(jīng)常會面對兩個錯誤碼： 401 和 403 。通常而言， 401 就是未登錄的意思，需要認證； 403 就是禁止訪問的意思，需要授權(quán)。

3.1       認證

Istio 提供兩種類型的身份認證：

l   傳輸身份認證，也稱為服務(wù)到服務(wù)身份認證：對直連客戶端進行驗證。 Istio 提供雙向 TLS 作為傳輸身份認證的全棧解決方案。我們可以輕松啟用此功能，而無需更改服務(wù)代碼。這個解決方案：

l   為每個服務(wù)提供強大的身份認定，以實現(xiàn)跨群集和跨云的互操作性。

l   保護服務(wù)到服務(wù)通信和最終用戶到服務(wù)通信。

l   提供密鑰管理系統(tǒng)，以自動執(zhí)行密鑰和證書生成，分發(fā)和輪換。

l   來源身份認證，也稱為終端用戶身份認證：對來自終端用戶或設(shè)備的原始客戶端請求進行驗證。 Istio 通過 JSON Web Token （ JWT ）、 Auth0 、 Firebase Auth 、 Google Auth 和自定義身份認證來簡化開發(fā)者的工作，使之輕松實現(xiàn)請求級別的身份認證。

在這兩種情況下， Istio 都通過自定義 Kubernetes API 將身份認證策略存儲在 Istio 配置存儲（ Istio config store ）中。 Pilot 會在適當?shù)臅r候進行同步，為每個 Proxy 更新其最新狀態(tài)以及密鑰。此外， Istio 支持在許可模式下進行身份認證，以幫助我們理解策略變更前后，服務(wù)的安全狀態(tài)是如何變化的。

3.1.1         認證架構(gòu)

我們可以使用身份認證策略，為 Istio 網(wǎng)格中接收請求的服務(wù)指定身份認證要求。我們使用 .yaml 文件來配置策略，策略將保存在 Istio 配置存儲中。在任何策略變更后， Pilot 會將新策略轉(zhuǎn)換為適當?shù)呐渲茫掳l(fā)給 Envoy ，告知其如何執(zhí)行所需的身份認證機制。 Pilot 可以獲取公鑰并將其附加到 JWT 進行配置驗證。或者， Pilot 提供 Istio 系統(tǒng)管理的密鑰和證書的路徑，并將它們安裝到負載 Pod 中，以進行雙向 TLS 。

本文多次提到雙向 TLS 認證，讓我們理解一下其在 Istio 里的實現(xiàn)。 Istio 通過客戶端和服務(wù)端各自配備的 Envoy 進行通信，也就是說，客戶端和服務(wù)端的流量，是被各自的 Envoy 接管了的。對于客戶端調(diào)用服務(wù)端，遵循的步驟是：

1.          Istio 將出站流量從客戶端重新路由到客戶端的本地 Envoy 。

2.          客戶端 Envoy 與服務(wù)端 Envoy 開始雙向 TLS 握手。在握手期間，客戶端 Envoy 還執(zhí)行安全命名檢查，以驗證服務(wù)證書中提供的服務(wù)帳戶是否有權(quán)運行目標服務(wù)。

3.          客戶端 Envoy 和服務(wù)端 Envoy 建立了一個雙向的 TLS 連接， Istio 將流量從客戶端 Envoy 轉(zhuǎn)發(fā)到服務(wù)端 Envoy 。

4.          授權(quán)后，服務(wù)端 Envoy 通過本地 TCP 連接將流量轉(zhuǎn)發(fā)到服務(wù)端的服務(wù)。

3.1.2         認證策略配置

和其他的 Istio 配置一樣，可以用  .yaml  文件的形式來編寫認證策略，然后使用  Istioctl  二進制工具進行部署。如下圖的配置，通過配置 Policy 文件，對 reviews 服務(wù)進行了傳輸身份認證的配置，要求其必須使用雙向 TLS 做認證。

apiVersion : "authentication.Istio.io/v1alpha1"

kind : "Policy"

metadata :

  name : "reviews"

spec :

  targets :

  - name : reviews

    peers :

  - mtls : {}

3.2       授權(quán)

Istio 的授權(quán)功能，也稱為基于角色的訪問控制（ RBAC ），為 Istio 服務(wù)網(wǎng)格中的服務(wù)提供命名空間級別，服務(wù)級別和方法級別的訪問控制。它的特點是：

l   基于角色的語義，簡單易用。

l   包含服務(wù)到服務(wù)和終端用戶到服務(wù)兩種授權(quán)模式。

l   通過自定義屬性靈活定制授權(quán)策略，例如條件，角色和角色綁定。

l   高性能，因為 Istio 授權(quán)功能是在 Envoy 里執(zhí)行的。

3.2.1         授權(quán)架構(gòu)

上圖顯示了基本的 Istio 授權(quán)架構(gòu)。和認證的生效過程一樣，運維人員使用 .yaml 文件指定 Istio 授權(quán)策略。部署后， Istio 將策略保存在 Istio Config Store 中。 Pilot 會一直監(jiān)視 Istio 授權(quán)策略的變更，如果發(fā)現(xiàn)任何更改，它將獲取更新的授權(quán)策略，并將 Istio 授權(quán)策略分發(fā)給與服務(wù)實例位于同一 pod 內(nèi)的 Envoy 代理。

每個 Envoy 代理都運行一個授權(quán)引擎，該引擎在運行時授權(quán)請求。當請求到達代理時，授權(quán)引擎根據(jù)當前授權(quán)策略評估請求上下文，并返回授權(quán)結(jié)果 ALLOW 或 DENY 。

3.2.2         授權(quán)策略配置

我們可以使用 RbacConfig 啟用授權(quán)策略，并使用 ServiceRole 和 ServiceRoleBinding 配置授權(quán)策略。

RbacConfig 是一個網(wǎng)格維度的單例，其固定名稱值為 default ，也就是說我們只能在網(wǎng)格中配置一個 RbacConfig 實例。與其他 Istio 配置對象一樣， RbacConfig 被定義為 Kubernetes CustomResourceDefinition (CRD) 對象。

在 RbacConfig 中，運算符可以指定 mode 值，它可以是：

l   OFF ：禁用 Istio 授權(quán)。

l   ON ：為網(wǎng)格中的所有服務(wù)啟用了 Istio 授權(quán)。

l   ON_WITH_INCLUSION ：僅對包含字段中指定的服務(wù)和命名空間啟用 Istio 授權(quán)。

l   ON_WITH_EXCLUSION ：除了排除字段中指定的服務(wù)和命名空間外，網(wǎng)格中的所有服務(wù)都啟用 Istio 授權(quán)。

在以下示例中，為 default 命名空間啟用了 Istio 授權(quán)，。

apiVersion : "rbac.Istio.io/v1alpha1"

kind : RbacConfig

metadata :

  name : default

  namespace : Istio-system

spec :

  mode : 'ON_WITH_INCLUSION'

  inclusion :

    namespaces : [ "default" ]

針對服務(wù)和命名空間啟用授權(quán)后，我們還需要配置具體的授權(quán)策略，這通過配置 ServiceRole 和 ServiceRoleBinding 實現(xiàn)。與其他 Istio 配置對象一樣，它們同樣被定義為 CRD 對象。

ServiceRole 定義了一組訪問服務(wù)的權(quán)限。 ServiceRoleBinding 向特定對象授予 ServiceRole ，例如用戶，組或服務(wù)。

ServiceRole 和 ServiceRoleBinding 組合規(guī)定了： 允許誰在哪些條件下做什么，具體而言：

l   誰指的是 ServiceRoleBinding 中的 subject 部分。

l   做什么指的是 ServiceRole 中的 rule 部分。

l   哪些條件指的是我們可以在 ServiceRole 或 ServiceRoleBinding 中使用 Istio Attributes 指定的 condition 部分。

讓我們再舉一個簡單的例子，如下圖， ServiceRole 和 ServiceRoleBinding 的配置規(guī)定：將所有用戶（ user=“*” ）綁定為（ products-viewer ）角色，這個角色可以對 products 這個服務(wù)發(fā)起 GET 或 HEAD 請求，但是其限制條件是請求頭必須包含 version ，且值為 v1 或 v2 。

apiVersion : "rbac.Istio.io/v1alpha1"

kind : ServiceRole

metadata :

  name : products-viewer

  namespace : default

spec :

  rules :

  - services : [ "products" ]

methods : [ "GET" , "HEAD" ]

    constraints :

    - key : request.headers[version]

      values : [ "v1" , "v2" ]

---

apiVersion : "rbac.Istio.io/v1alpha1"

kind : ServiceRoleBinding

metadata :

  name : binding-products-allusers

  namespace : default

spec :

  subjects :

  - user : "*"

  roleRef :

    kind : ServiceRole

    name : "products-viewer"

 

至此，我們做個簡單的總結(jié)： 單體應(yīng)用程序拆分成成千上百個服務(wù)后，帶來了安全問題， Istio 嘗試在由服務(wù)組成的服務(wù)網(wǎng)格里，加入了一套全棧解決方案。這套方案里， Istio 默默處理了大部分安全基礎(chǔ)設(shè)施，但也暴露了認證和授權(quán)兩個功能讓用戶進行自定義配置。我們通過 Policy 、 MeshPolicy 以及 RbacConfig 、 ServiceRole 、 ServiceRoleBinding 就可以完成對認證和授權(quán)環(huán)節(jié)所有功能的配置，而不需要侵入地改動任何服務(wù)的代碼。

https://www.huaweicloud.com/product/cce.html

網(wǎng)站名稱：Istio技術(shù)與實踐6：Istio如何為服務(wù)提供安全防護能力-創(chuàng)新互聯(lián)
地址分享：http://vcdvsql.cn/article22/dshhjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站營銷、商城網(wǎng)站、網(wǎng)站設(shè)計公司、微信公眾號、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)