セキュリティポリシーの例

背景

このページでは、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"]

名前空間の分離

以下の2つのポリシーは、名前空間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"]

イングレス例外を使用した名前空間の分離

以下の2つのポリシーは、名前空間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 を要求する(防御の深化)

PeerAuthenticationSTRICTに設定しましたが、承認レイヤーで追加のチェックを行うことで、トラフィックが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"]
この情報は役に立ちましたか?
改善のための提案はありますか?

ご意見ありがとうございました!