Istio的安全(概念)

本文轉載自查看原文 2020-08-31 11:26 926 kubernetes/ istio

Istio 安全(概念)

Istio 安全(概念)

通過將一個單一應用划分為多個原子服務的方式，可以提供更好的靈活性，可擴展性以及重用服務的能力。然而微服務對安全有特殊的要求：

抵御中間人攻擊，需要用到流量加密
提供靈活的服務訪問控制，需要用到TLS和細粒度訪問策略
決定哪些人在哪些時間可以做哪些事，需要用到審計工具

為了解決這些問題，istio提供了完整的安全方案。本章節全面介紹了如何使用istio對服務進行安全加固(無論該服務運行在哪里)。特別地，Istio的安全性可減輕來自內部和外部的(對數據，終端，通信和平台的)威脅。

Istio安全特性提供了強大的身份、策略、透明TLS加密，以及認證，授權和審計(AAA)等功能來對服務和數據進行防護。istio安全的目標是：

默認安全：不需要對應用代碼和基礎架構進行任何改變
深度防護：與現有的安全系統結合，來提供多個層面的防護
0-信任網絡：在不信任的網絡上構建安全解決方案

查看multual TLS遷移文檔，了解如何在已部署的服務上使用istio安全特性。通過安全任務了解更多的細節。

高層架構

istio的安全涉及多個組件：

用於密鑰和證書管理的證書頒發機構（CA）
分發給代理的API server配置：
Sidecar和外圍代理作為策略執行點(pep)來確保客戶端和服務器之間的通信安全。
通過一系列Envoy擴展來管理遙測和審計

控制面負責接收來自API server的配置信息，並在數據面配置PEP。PEP使用Envoy實現。架構如下，可以看到各個Envoy代理直接可以使用mTLS實現(默認啟用ISTIO_MUTUAL)

Istio身份

身份是所有安全設施的最基本概念。在工作負載到工作負載的通信開始時，雙方必須交換攜帶各自身份信息的憑據來進行雙向認證。客戶端會將服務的身份與安全命名信息進行比對，來查看該服務是否是授權的工作負載運行器；服務端會根據授權策略來決定客戶端可以訪問的內容，審計記錄誰在什么時間訪問了什么內容，根據負載控制客戶端的行為，以及拒絕沒有支付被訪問負載的客戶端。

istio身份模型使用一級服務標識(service identity )來確定請求源的身份。該模型使用更大的靈活性和顆粒度來標識一個用戶，單獨的負載，或一組負載。在沒有服務標識的平台上，isito可以使用其他標識來對負載實例進行分組，如服務名稱。

下面展示了不同平台上可以使用的服務標識：

Kubernetes: Kubernetes service account
GKE/GCE: GCP service account
GCP: GCP service account
AWS: AWS IAM user/role account
On-premises (non-Kubernetes): user account, custom service account, service name, Istio service account, or GCP service account. The custom service account refers to the existing service account just like the identities that the customer’s Identity Directory manages.

身份和證書管理

istio的安全使用X.509證書為每個負載提高了強身份標識。每個Envoy代理旁都會運行一個istio agent，istio agent與istiod配合，可以在擴展時實現證書的自動滾動。下面展示了證書配置流程：

isito通過secert發現(SDS)機制來處理身份認證，處理過程為：

istiod提供了一個gRPC服務來處理CSR(證書簽名請求)
Envoy通過Envoy SDS API發送證書和密鑰請求
在接收到SDS請求后，istio agent會(在將攜帶憑據的CSR發送istiod前)創建私鑰和CSR
CA會校驗CSR攜帶的憑據，並簽發CSR來生成證書
istio agent通過Envoy SDS API將來自isitod的證書和密鑰發送給Envoy
周期性地執行如上CSR處理流程來滾動證書和密鑰

認證

isito提供兩種類型的認證：

對等認證：用於服務到服務的身份驗證，驗證建立連接的客戶端。Istio提供了mutual TLS作為傳輸身份驗證的全棧解決方案，這種方式無需修改服務代碼，該方案：
- 為每個服務提供了強標識作為角色(role)，支持跨集群和雲的互操作性。
- 確保服務到服務的通信安全。
- 提供了密鑰管理系統來自動生成，分發，滾動密鑰和證書。
請求認證：用於終端用戶認證，校驗請求中的憑據。Istio請求級認證使用了JSON Web Token(JWT)驗證，以及基於自定義身份驗證或OpenID Connect開發的程序，如：

在所有場景中，istio通過一個用戶自定義的Kubernetes API將認證策略保存在Istio config store 中。istiod會將這些策略更新到每個代理中，並提供合適的密鑰。此外，istio支持permissive 模式的身份驗證，可以幫助理解一個策略在強制執行前如何影響安全狀態。

Mutial TLS認證

Istio通過客戶端和服務器端的PEP實現服務到服務的通信，PEP使用Envoy代理來實現。當一個負載使用mutual TLS認證向另一個負載發送請求時，該請求的處理流程如下：

isito將出站流量從客戶端重路由到客戶端的本地sidecar Envoy中
客戶端側的Envoy與服務端側的Envoy開始雙向TLS握手。在握手期間，客戶端側的Envoy也會進行安全命名校驗，確保可以通過授權服務端證書中的service account來執行目標服務。
客戶端側的Envoy和服務端側的Envoy建立雙向TLS連接，istio會將流量從客戶端的Envoy轉發到服務端側的Envoy
在授權后，服務端測的Envoy會通過本地TCP連接將流量轉發到服務端的服務中。

寬容(Permissive)模式

istio mutual TLS有一個寬容模式，它允許一個服務同時接收明文流量和TLS加密的流量。該特性極大提升了mutual TLS的使用體驗。

在很多非istio的客戶端和非istio的服務端架構中，當計划將服務端遷移到啟用mutual TLS的istio上時都會遇到問題。通常，操作人員無法同時給所有的客戶端安裝一個sidecar，或沒有權限這么做。即使在所有的服務端安裝istio sidecar后，操作人員仍然無法在不中斷現有連接的情況下啟用mutual TLS。

使用寬容模式時，服務端可以同時接收明文和mutual TLS的流量。該模式極大提升了使用istio的靈活性。服務端在安裝istio sidecar后，也可以在不中斷現有明文流量的情況下接收mutual TLS流量。這樣，就可以通過逐步安裝並配置客戶端的istio sidecar來發送mutual TLS流量。一旦完成客戶端的配置，操作人員就可以將服務端配置為僅mutual TLS模式。更多信息，參見mutual TLS遷移指南。

安全命名

服務的憑據編碼到了證書中，但服務名稱是通過發現服務或DNS進行檢索的。安全命名信息將服務的身份信息映射到服務名稱上。一個身份A映射到服務名稱B，表示授權A運行服務B。控制面會通過watch apiserver來生成安全命名映射，並將其安全地分發到PEP上。下面解釋安全命名為什么對認證至關重要。

假設合法的服務器運行了服務datastore，且僅使用了infra-team身份。一個惡意的用戶使用了test-team身份的證書和密鑰，該用戶嘗試冒充服務來分析來自客戶端的數據。該惡意用戶使用test-team身份的證書和密鑰部署了一個偽造的服務器。假設該惡意用戶成功劫持(通過DNS欺騙，BGP/路由劫持，ARP欺騙等)了發往datastore的流量，並將流量重定向到偽造的服務。

當一個客戶端調用datastore服務時，它會從服務的證書中抽取出test-team身份，然后使用安全命名信息校驗test-team是否允許運行datastore，此時客戶端會探測到test-team不允許datastore服務，認證失敗。

安全命名能夠防止HTTPS流量被網絡劫持，也能夠防止TCP流量被網絡劫持。但安全命名無法防止DNS欺騙，因為這種情況下，攻擊者會劫持DNS並修改目的地的IP地址，而TCP流量不包含主機信息，僅能依賴IP地址進行路由。事實上，這種DNS劫持甚至在客戶端的Envoy收到流量之前就有可能發生。

認證架構

可以使用對等和請求認證策略為在Istio網格中接收請求的工作負載指定身份認證。網格操作人員可以使用.yaml文件指定策略。一旦部署后，會將策略保存在istio的配置存儲中。isito控制器會監視配置存儲。

當策略變更后，新的策略會轉變為合適的配置，告訴PEP如何執行需要的認證機制。控制平面可能會拉取公鑰，並將其添加到配置中，用於JWT校驗。或者，isito會提供istio系統管理的密鑰和證書的路徑，並將它們安裝到應用pod中，用於mutual TLS。更多參見身份和證書管理。

istio會異步地將配置發送給目標終端。一旦代理接收到該配置，新的配置會在該pod上立即生效。

發送請求的客戶端服務負責遵循必要的身份認證機制。對於對等認證，應用負責獲取JWT憑證並將其附加到請求上；對於mutual TLS，istio會自動在兩個PEP間自動升級所有的流量。如果認證取消了mutual TLS模式，isito會在PEP間繼續使用明文。為了覆蓋這種行為，需要在destination rules中取消mutual TLS模式。

istio會使用上述兩種認證方式，以及憑證中聲明的其他信息（如果適用）將身份信息輸出到下一層：授權。

認證策略

本節展示了istio認證策略的工作細節。身份認證策略應用於服務接收的請求，為了在mutual TLS中給指定客戶端側的認證規則，需要在DestinationRule中指定TLSSettings，更多參見TLS設置文檔。

與其他istio配置類似，可以在.yaml文件中指定配置策略，並使用kubectl部署。下面的認證策略指定了帶app:reviews標簽的負載的傳輸認證必須使用mutual TLS。

DestinationRule中設置使用哪種類型的TLS：DISABLE|SIMPLE|MUTUAL|ISTIO_MUTUAL，然后在單獨的資源中指定具體的認證和授權策略(當然也可以單獨使用認證和授權策略)。

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "example-peer-policy"
  namespace: "foo"
spec:
  selector:
    matchLabels:
      app: reviews
  mtls:
    mode: STRICT

mtls的模式如下：

Name Description

UNSET Inherit from parent, if has one. Otherwise treated as PERMISSIVE.

DISABLE Connection is not tunneled.

PERMISSIVE Connection can be either plaintext or mTLS tunnel.

STRICT Connection is an mTLS tunnel (TLS with client cert must be presented).

Name	Description
`UNSET`	Inherit from parent, if has one. Otherwise treated as PERMISSIVE.
`DISABLE`	Connection is not tunneled.
`PERMISSIVE`	Connection can be either plaintext or mTLS tunnel.
`STRICT`	Connection is an mTLS tunnel (TLS with client cert must be presented).

策略存儲

istio將網格范圍的策略保存在根命名空間中。這些策略有一個空的selector，應用到網格中的所有負載上。帶命名空間的策略會保存到對應的命名空間中，僅應用到該命名空間中的負載上。如果配置了selector字段，認證策略僅會應用到匹配的負載上。

對等和請求認證策類型分別為PeerAuthentication和RequestAuthentication。

Selector字段

對等和請求認證策略使用selector字段指定應用策略的負載標簽。下例展示了一個策略的selector字段，應用到具有app:product-page標簽的負載。

selector:
     matchLabels:
       app:product-page

如果沒有為selector字段提供任何值，策略會應用到其存儲范圍內的所有負載上。通過selector字段可以幫助指定策略的作用范圍：

網絡范圍策略：根命名空間中的策略，不使用selector字段或使用空的selector字段
命名空間范圍策略：特定的非根命名空間中的策略，不使用selector字段或使用空的selector字段
指定負載策略：定義在常規命名空間中的策略，使用非空的selector字段

對等方和請求身份驗證策略對selector字段遵循相同的層次結構原則，但Istio會以稍微不同的方式組合和應用它們。

只能存在一個網格范圍的對等認證策略，每個命名空間中只能存在一個命名空間范圍的對等認證策略。在相同的網格或命名空間中配置多網格范圍或多命名空間范圍的對等認證策略時，istio或忽略新添加的策略。當匹配到多個指定負載的對等認證策略時，istio會選擇最老的一條。

Istio按照以下順序為每個工作負載指定應用范圍最小的匹配策略：

指定負載
命名空間范圍
網格范圍

Istio可以將所有匹配的請求身份認證策略組合起來，就如同這些策略為單個請求身份認證策略一樣。因此，可以在一個網格或命名空間中存在多個網格范圍或命名空間范圍的策略。但是，最好避免存在多個網格范圍或命名空間范圍的請求認證策略。

對等認證

對等認證策略強制在目標負載上指定了mutual TLS模型。支持如下模型：

PERMISSIVE：負載同時接受mutual TLS和明文流量。該模式通常用於遷移不帶sidecar的負載，此時該負載無法使用mutual TLS。一旦負載遷移結束，並注入sidecar，此時應該將模式切換為STRICT。
STRICT：負載僅接受mutual TLS流量。
DISABLE：禁用mutual TLS。從安全的角度看，除非提供了其他安全方案，否則不應該使用該模式

如果沒有設置模式，則會繼承父范圍的模式。網格范圍的對等認證策略默認使用PERMISSIVE模式。

下面的對等認證策略要求命名空間foo中的所有負載使用mutual TLS。

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "example-policy"
  namespace: "foo"
spec:
  mtls:
    mode: STRICT

使用指定負載的對等認證策略時，可以為不同的端口指定不同的mutual TLS模式。下例中，禁止在 app:example-app 負載的80端口上使用mutual TLS，而其他端口使用命名空間范圍的對等認證策略。

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "example-workload-policy"
  namespace: "foo"
spec:
  selector:
     matchLabels:
       app: example-app
  portLevelMtls:
    80:
      mode: DISABLE

portLevelMtls可以對不同的端口應用不同的認證策略

下面的service配置將來自負載example-app的請求綁定到example-service的80端口，只有這樣，上述的對等認證策略才能運行。

apiVersion: v1
kind: Service
metadata:
  name: example-service
  namespace: foo
spec:
  ports:
  - name: http
    port: 8000
    protocol: TCP
    targetPort: 80
  selector:
    app: example-app

請求認證

請求認證策略指定了校驗JSON Web Token (JWT)的值。這些值包括：

請求中的token的位置
發起者或請求
公共的JSON Web Key Set (JWKS)

istio校驗出現的token，如果違反請求身份認證策略中的規則，則視為無效的token，拒絕該請求。如果請求中沒有攜帶token，默認情況下會接受這些請求。為了拒絕不帶token的請求，需要通過認證規則(例如路徑或動作)限制特定的操作。

如果每個請求身份認證策略使用唯一的位置，則可以指定多個JWT。當多個策略匹配到一個負載時，istio會將所有的規則結合起來(就像一個獨立的策略一樣)。這種方式對於編寫可以接受來自不同提供方的JWT的工作負載來說非常有用。然而，無法支持具有多個JWT的請求，因為未定義這類請求的輸出主體。

主體(Principals)

當使用對等認證策略和mutual TLS時，istio會從對等認證中抽取身份信息，並保存到source.principal中。類似地，當使用請求認證策略時，istio會將JWT的身份信息分配到 request.auth.principal中。isito使用這些主體設置認證策略和遙測輸出。

對於mutual TLS來說主體為k8s的service account；對於請求認證來說，主體為使用分隔符組合起來的JWT token的iss和sub claim。參見source

升級認證策略

可以在任何時候修改認證策略，isito會將新的策略實時推送到負載上。然而，isito不能保證所有的負載在同一時間接收到新的策略。以下實現幫助避免在更新認證策略時導致的混亂：

在將模式從DISABLE 切換到STRICT時，中間對等身份認證策略使用PERMISSIVE模式，反之亦然。當所有的負載切換到期望的模式后，可以將策略修改為最終的模式。可以使用isito的遙測校驗負載是否切換成功。
當請求認證策略從JTW切換到另一個JWT時，將新的JWT的規則添加到策略中，而不刪除舊的規則。此時負載會接受兩個類型的JWT，當所有的流量切換到新的JWT時，就可以移除老的規則。然而，每個JWT都需要使用不同的位置。

授權

istio的授權特性提供了網格，命名空間和負載范圍內的訪問控制。這些不同級別的控制提供了如下便利：

負載到負載以及終端用戶到負載的授權
簡單的API：包括一個便於使用和維護的AuthorizationPolicy CRD
靈活的語義：操作人員可以在Istio屬性上定義自定義條件，並使用DENY和ALLOW導動作。
高性能：istio的授權運行在本地的Envoy上。
高兼容性：支持給RPC，HTTP，HTTPS和HTTP2，以及普通TCP協議。

授權架構

每個Envoy代理都運行了一個在運行時授權請求的授權引擎。當代理接收到一個請求，授權引擎會使用當前的授權策略評估請求上下文，並返回授權結果，ALLOW 或DENY。操作人員可以在.yaml文件中指定授權策略。

隱式啟用

無需明確啟用istio的授權特性。只需將授權策略應用於工作負載即可執行訪問控制。對於未應用授權策略的工作負載，Istio不會執行允許所有請求的訪問控制。

授權策略支持ALLOW和DENY，deny 策略優先allow 策略。如果allow 策略應用到一個負載，則對該負載的訪問默認是deny 的，除非明確在策略規則中允許該訪問。當一個負載上應用了而多個授權策略，則istio會疊加這些策略。

授權策略

為了配置授權策略，需要創建一個名為AuthorizationPolicy 的自定義資源。一個授權策略包含一個selector，一個action和一個rules列表：

selector字段指定了策略的目標
action字段指定了是否允許或拒絕請求。
rules指定了何時觸發action
- rules中的from字段指定了請求源
- rules中的to字段指定了請求的操作
- when字段指定了應用規則的條件

下面例子展示了允許兩個源的授權策略，即cluster.local/ns/default/sa/sleep service account和dev命名空間，在請求發送了有效的JWT token后可以訪問帶有foo命名空間中帶有app: httpbin和version: v1 標簽的負載

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy #授權策略資源
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/sleep"]
   - source:
       namespaces: ["dev"]
   to:
   - operation:
       methods: ["GET"]
   when:
   - key: request.auth.claims[iss]
     values: ["https://accounts.google.com"]

下例的授權策略拒絕來自非foo命名空間的source的請求。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin-deny
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: DENY
 rules:
 - from:
   - source:
       notNamespaces: ["foo"]

拒絕策略優先於允許策略。如果匹配了一個deny策略，即使匹配到allow策略，此時也應該拒絕該請求。isito會首先評估deny策略，保證allow策略不會繞過deny策略。

策略目標

可以使用 metadata/namespace 字段和可選的selector 字段來決定策略的范圍和策略的目標。策略會應用到metadata/namespace字段中的命名空間。如果該值設置到了根命名空間，則策略會應用到網格中的所有命名空間。根命名空間是可配置的，默認為istio-system。如果設置為其他命名空間，則策略僅會應用到指定的命名空間。

可以使用selector字段進一步限制策略應用的負載。selector使用標簽來選擇目標負載。selector包含一些列{key: value} 對，key為標簽的名稱。如果沒有設置，授權策略會應用到相同命名空間中的所有負載上。

例如，allow-read策略允許使用"GET" 和"HEAD" 訪問default命名空間中帶有app: products 標簽的負載。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-read
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
         methods: ["GET", "HEAD"]

值匹配

授權策略中的大部分字段支持下面的匹配框架：

完全匹配：字符串完全匹配。
前綴匹配：使用"*"結尾的字符串。例如 "test.abc.*" 匹配"test.abc.com", "test.abc.com.cn", "test.abc.org"等。
后綴匹配：使用"*"開頭的字符串。例如 "*.abc.com" 匹配"eng.abc.com", "test.eng.abc.com"等。
存在匹配：使用*指定非空的字符串。可以使用 fieldname: ["*"]格式指定一個必須存在的字段，不同於未指定字段，未指定字段可以匹配任何內容，包括空的。

這里有一些例外，如以下字段僅支持完全匹配：

when部分的key字段
under部分的ipBlocks字段
to部分的ports字段

下例中展示了策略允許訪問/test/* 作為前綴或使用*/info 作為后綴的路徑。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: tester
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/test/*", "*/info"]

排除匹配

為了匹配像when字段中的notValue，source字段中的notIpBlocks，to字段中的notPorts之類的消極條件，istio支持排除匹配。下例策略允許請求路徑非/healthz，且由JWT認證的有效的請求主體。這樣策略會排除使用JWT認證的到/healthz的請求。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: disable-jwt-for-healthz
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
        notPaths: ["/healthz"]
    from:
    - source:
        requestPrincipals: ["*"]

下例會拒絕到達/admin路徑的不帶請求主體的請求。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: enable-jwt-for-admin
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/admin"]
    from:
    - source:
        notRequestPrincipals: ["*"]

允許所有以及默認拒絕所有認證策略

下例展示了一個簡單的allow-all認證策略，該策略允許訪問default命名空間中的所有負載。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  action: ALLOW
  rules:
  - {}

下例的策略拒絕訪問admin命名空間的所有負載：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: admin
spec:
  {}

自定義條件

可以在when部分指定其他條件。例如，如下AuthorizationPolicy定義包含一個條件，即 request.headers[version] 為"v1" 或 "v2"。這種情況下，key為request.headers[version]，屬於istio request.headers屬性中的一項，類型為map。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/sleep"]
   to:
   - operation:
       methods: ["GET"]
   when:
   - key: request.headers[version]
     values: ["v1", "v2"]

支持的key可以參見官方文檔

認證和未認證的身份

如果要將一個負載可以公開訪問，需要將source部分置為空。這樣會允許所有(認證和未認證的)的用戶和負載進行訪問，如：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - to:
   - operation:
       methods: ["GET", "POST"]

如果要僅允許認證的用戶，將principals設置為*，如：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["*"]
   to:
   - operation:
       methods: ["GET", "POST"]

使用istio授權普通TCP協議

isito授權支持負載使用普通TCP協議，如MongoDB。這種情況下的授權策略的配置與HTTP負載相同，不同之處在於，特定的字段和條件僅適用於HTTP工作負載，這些字段包括：

授權策略對象的source部分的request_principals 字段
授權策略對象的operation部分的hosts, methods 和paths 字段

支持的條件參見官方文檔。如果TCP負載中使用了任何僅HTTP支持的字段，則istio會在授權策略中忽略這些僅HTTP格式的字段。

假設一個MongoDB服務的端口為27017，下例配置了一個授權策略，僅允許istio網格中的bookinfo-ratings-v2 服務訪問MongoDB負載。

apiVersion: "security.istio.io/v1beta1"
kind: AuthorizationPolicy
metadata:
  name: mongodb-policy
  namespace: default
spec:
 selector:
   matchLabels:
     app: mongodb
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/bookinfo-ratings-v2"]
   to:
   - operation:
       ports: ["27017"]

mutual TLS的依賴

Istio使用mutual TLS將信息從客戶端安全地傳遞到服務器。必須在授權策略中使用如下字段前啟用mutual TLS。

source部分的principals字段
source部分的namespaces字段
source.principal自定義條件
source.namespace 自定義條件
connection.sni自定義條件

如果授權策略中沒有使用上述任何一個字段，則不需要mutual TLS。

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 istio入門（02）istio的架構和概念 Istio的流量管理(概念) Istio安全-認證(實操二) Istio安全-授權(實操三) Istio安全-證書管理(實操一) Istio 服務網格istio概念應知應會 Service Mesh(服務網格)概念及Istio初體驗 SSL安全證書-概念解析信息安全基本概念