Istio技術(shù)與實(shí)踐6：Istio如何為服務(wù)提供安全防護(hù)能力-創(chuàng)新互聯(lián)

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

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

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

那么，便引出 3 個(gè)問題：

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

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

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

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

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

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

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

l   要審計(jì)誰在什么時(shí)候做了什么，需要審計(jì)工具

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

如上圖所示，

Istio 安全的三大目標(biāo)是：

l   默認(rèn)安全（ 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)建安全解決方案。

為了實(shí)現(xiàn)這 3 個(gè)目標(biāo)， Istio 安全功能提供了 4 大守護(hù)系統(tǒng)：

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

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

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

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

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

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

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

2.1       Istio 安全架構(gòu)

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

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

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

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

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

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

2.2       兩個(gè)安全基本概念

2.2.1         Identity

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

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

不同平臺(tái)上的 Istio 服務(wù)標(biāo)識(shí)：

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

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

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

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

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

2.2.2   PKI  

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1       認(rèn)證

Istio 提供兩種類型的身份認(rèn)證：

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

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

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

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

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

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

3.1.1         認(rèn)證架構(gòu)

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

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

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

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

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

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

3.1.2         認(rèn)證策略配置

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

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ù)提供命名空間級(jí)別，服務(wù)級(jí)別和方法級(jí)別的訪問控制。它的特點(diǎn)是：

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

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

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

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

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

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

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

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

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

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

在 RbacConfig 中，運(yùn)算符可以指定 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 實(shí)現(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 部分。

讓我們再舉一個(gè)簡單的例子，如下圖， ServiceRole 和 ServiceRoleBinding 的配置規(guī)定：將所有用戶（ user=“*” ）綁定為（ products-viewer ）角色，這個(gè)角色可以對 products 這個(gè)服務(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"

 

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

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

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

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

廣告

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