安全策略範例

3 分鐘閱讀時間頁面測試

背景

此頁面顯示使用 Istio 安全策略的常見模式。您可能會發現它們在您的部署中很有用，或將其用作範例策略的快速參考。

此處展示的策略僅為範例，在應用之前需要變更以適應您的實際環境。

另請閱讀身份驗證和授權任務，以獲得更詳細使用安全策略的實作教學。

每個主機需要不同的 JWT 發行者

JWT 驗證在入口閘道上很常見，您可能希望針對不同的主機要求不同的 JWT 發行者。除了請求身份驗證策略之外，您還可以使用授權策略進行細粒度的 JWT 驗證。

如果您想在 JWT 主體匹配的情況下允許訪問給定的主機，請使用以下策略。對其他主機的訪問將始終被拒絕。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: jwt-per-host
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - from:
    - source:
        # the JWT token must have issuer with suffix "@example.com"
        requestPrincipals: ["*@example.com"]
    to:
    - operation:
        hosts: ["example.com", "*.example.com"]
  - from:
    - source:
        # the JWT token must have issuer with suffix "@another.org"
        requestPrincipals: ["*@another.org"]
    to:
    - operation:
        hosts: [".another.org", "*.another.org"]

命名空間隔離

以下兩個策略在命名空間 foo 上啟用嚴格的 mTLS，並允許來自同一命名空間的流量。

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: foo-isolation
  namespace: foo
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["foo"]

具有入口例外情況的命名空間隔離

以下兩個策略在命名空間 foo 上啟用嚴格的 mTLS，並允許來自同一命名空間和入口閘道的流量。

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: ns-isolation-except-ingress
  namespace: foo
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["foo"]
    - source:
        principals: ["cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"]

在授權層要求 mTLS（深度防禦）

您已將 PeerAuthentication 配置為 STRICT，但希望確保流量確實受到 mTLS 的保護，並在授權層進行額外檢查，即深度防禦。

如果主體為空，以下策略將拒絕請求。如果使用純文本，主體將為空。換句話說，如果主體為非空，則該策略允許請求。 "*" 表示非空匹配，與 notPrincipals 一起使用表示匹配空主體。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-mtls
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        notPrincipals: ["*"]

要求使用 `DENY` 策略進行強制授權檢查

如果您想要求必須滿足且不能被另一個更寬鬆的 ALLOW 策略繞過的強制授權檢查，您可以使用 DENY 策略。這是因為 DENY 策略優先於 ALLOW 策略，並且可以在 ALLOW 策略之前提前拒絕請求。

除了請求身份驗證策略之外，還可以使用以下策略來強制執行強制 JWT 驗證。如果請求主體為空，則該策略將拒絕請求。如果 JWT 驗證失敗，請求主體將為空。換句話說，如果請求主體為非空，則該策略允許請求。 "*" 表示非空匹配，與 notRequestPrincipals 一起使用表示匹配空請求主體。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]

同樣，使用以下策略來要求強制命名空間隔離，並允許來自入口閘道的請求。如果命名空間不是 foo 且主體不是 cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account，則該策略將拒絕請求。換句話說，只有當命名空間是 foo 或主體是 cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account 時，該策略才允許請求。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: ns-isolation-except-ingress
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        notNamespaces: ["foo"]
        notPrincipals: ["cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"]