セキュリティ

 約23分  

モノリシックアプリケーションをアトミックサービスに分割することで、俊敏性、スケーラビリティ、サービスの再利用性の向上がもたらされます。しかし、マイクロサービスには独自のセキュリティニーズもあります。

  • 中間者攻撃から防御するために、トラフィックの暗号化が必要です。
  • 柔軟なサービスアクセスコントロールを提供するために、相互TLSと詳細なアクセスポリシーが必要です。
  • 誰がいつ何をしたかを判断するために、監査ツールが必要です。

Istio Securityは、これらの問題を解決するための包括的なセキュリティソリューションを提供します。このページでは、Istioのセキュリティ機能を使用して、サービスを実行する場所を問わずサービスを保護する方法の概要を説明します。特に、Istioセキュリティは、データ、エンドポイント、通信、およびプラットフォームに対する内部および外部の脅威の両方を軽減します。

Security overview
セキュリティの概要

Istioのセキュリティ機能は、強力なアイデンティティ、強力なポリシー、透過的なTLS暗号化、および認証、認可、監査（AAA）ツールを提供して、サービスとデータを保護します。Istioセキュリティの目標は次のとおりです。

  • デフォルトによるセキュリティ：アプリケーションコードとインフラストラクチャに変更は不要です。
  • 多層防御：既存のセキュリティシステムと統合して、複数の防御層を提供します。
  • ゼロトラストネットワーク：信頼できないネットワーク上にセキュリティソリューションを構築します。

展開済みのサービスでIstioセキュリティ機能の使用を開始するには、相互TLS移行ドキュメントをご覧ください。セキュリティ機能の詳細な手順については、セキュリティタスクをご覧ください。

ハイレベルアーキテクチャ

Istioのセキュリティには、複数のコンポーネントが関与します。

コントロールプレーンは、APIサーバーからの構成を処理し、データプレーン内のPEPを構成します。PEPはEnvoyを使用して実装されます。次の図はアーキテクチャを示しています。

Security Architecture
セキュリティアーキテクチャ

以降のセクションでは、Istioのセキュリティ機能を詳細に紹介します。

Istioアイデンティティ

アイデンティティは、あらゆるセキュリティインフラストラクチャの基本的な概念です。ワークロード間の通信の開始時に、両者は相互認証のために、アイデンティティ情報を含む資格情報を交換する必要があります。クライアント側では、サーバーのアイデンティティが安全なネーミング情報に対してチェックされ、ワークロードの実行が承認されているかどうかが確認されます。サーバー側では、サーバーは認可ポリシーに基づいてクライアントがアクセスできる情報を決定し、いつ誰が何にアクセスしたかを監査し、使用したワークロードに基づいてクライアントに料金を請求し、料金の支払いが行われなかったクライアントのワークロードへのアクセスを拒否できます。

Istioのアイデンティティモデルは、ファーストクラスのサービスアイデンティティを使用して、リクエストの元のアイデンティティを決定します。このモデルにより、サービスアイデンティティが人間のユーザー、個々のワークロード、またはワークロードのグループを表すための柔軟性と粒度が向上します。サービスアイデンティティがないプラットフォームでは、Istioはサービス名などのワークロードインスタンスをグループ化できる他のアイデンティティを使用できます。

次のリストは、さまざまなプラットフォームで使用できるサービスアイデンティティの例を示しています。

  • Kubernetes：Kubernetesサービスアカウント
  • GCE：GCPサービスアカウント
  • オンプレミス（非Kubernetes）：ユーザーアカウント、カスタムサービスアカウント、サービス名、Istioサービスアカウント、またはGCPサービスアカウント。カスタムサービスアカウントは、顧客のアイデンティティディレクトリが管理するアイデンティティと同様に、既存のサービスアカウントを参照します。

アイデンティティと証明書管理

Istioは、X.509証明書を使用して、すべてのワークロードに強力なアイデンティティを安全にプロビジョニングします。各Envoyプロキシとともに実行されるIstioエージェントは、istiodと連携して、大規模なキーと証明書のローテーションを自動化します。次の図は、アイデンティティプロビジョニングフローを示しています。

Identity Provisioning Workflow
アイデンティティプロビジョニングワークフロー

Istioは、次のフローを通じてキーと証明書をプロビジョニングします。

  1. istiodは、証明書署名要求（CSR）を受け取るためのgRPCサービスを提供します。
  2. 起動時に、Istioエージェントは秘密キーとCSRを作成し、資格情報とともにCSRをistiodに送信して署名させます。
  3. istiod内のCAは、CSRに含まれる資格情報を検証します。検証が成功すると、CSRに署名して証明書を生成します。
  4. ワークロードが起動されると、EnvoyはEnvoyシークレットディスカバリサービス（SDS）APIを介して、同じコンテナ内のIstioエージェントから証明書とキーを要求します。
  5. Istioエージェントは、istiodから受信した証明書と秘密キーを、Envoy SDS APIを介してEnvoyに送信します。
  6. Istioエージェントは、ワークロード証明書の有効期限を監視します。証明書とキーのローテーションのために、上記のプロセスが定期的に繰り返されます。

認証

Istioは2種類の認証を提供します。

  • ピア認証：接続しているクライアントを検証するためのサービス間認証に使用されます。Istioは、トランスポート認証のためのフルスタックソリューションとして相互TLSを提供しており、サービスコードを変更することなく有効にできます。このソリューションは、

    • 各サービスに、その役割を表す強力なアイデンティティを提供し、クラスタとクラウド全体での相互運用性を可能にします。
    • サービス間の通信を保護します。
    • キーと証明書の生成、配布、およびローテーションを自動化するキー管理システムを提供します。

  • リクエスト認証：リクエストに添付された資格情報を検証するためのエンドユーザー認証に使用されます。Istioは、JSON Webトークン（JWT）検証と、カスタム認証プロバイダーまたは任意のOpenID Connectプロバイダー（例：

を使用する合理化された開発者エクスペリエンスを使用して、リクエストレベルの認証を有効にします。いずれの場合も、IstioはカスタムKubernetes APIを介して認証ポリシーをIstio構成ストアに格納します。Istiodは、必要に応じてキーと共に、各プロキシに対してそれらを最新の状態に保ちます。さらに、Istioは許可モードでの認証をサポートしており、ポリシーの変更がセキュリティ体制に及ぼす影響を強制する前に理解するのに役立ちます。

相互TLS認証

Istioは、クライアント側とサーバー側のPEP（Envoyプロキシとして実装）を介してサービス間の通信をトンネリングします。ワークロードが相互TLS認証を使用して別のワークロードにリクエストを送信すると、リクエストは次のように処理されます。

  1. Istioは、クライアントからのアウトバウンドトラフィックをクライアントのローカルサイドカーEnvoyにリダイレクトします。
  2. クライアント側のEnvoyは、サーバー側のEnvoyと相互TLSハンドシェイクを開始します。ハンドシェイク中に、クライアント側のEnvoyは安全なネーミングチェックを実行して、サーバー証明書に提示されたサービスアカウントがターゲットサービスを実行することを許可されているかどうかを確認します。
  3. クライアント側のEnvoyとサーバー側のEnvoyは相互TLS接続を確立し、Istioはクライアント側のEnvoyからサーバー側のEnvoyにトラフィックを転送します。
  4. サーバー側のEnvoyはリクエストを認可します。認可された場合、ローカルTCP接続を介してバックエンドサービスにトラフィックを転送します。

Istioは、クライアントとサーバーの両方に対して、次の暗号スイートを使用してTLSv1_2を最小TLSバージョンとして構成します。

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • AES256-GCM-SHA384

  • AES128-GCM-SHA256

パーミッシブモード

Istio相互TLSには許可モードがあり、サービスはプレーンテキストトラフィックと相互TLSトラフィックの両方を同時に受け入れることができます。この機能により、相互TLSのオンボーディングエクスペリエンスが大幅に向上します。

相互TLSを有効にしてIstioにサーバーを移行したいオペレーターにとって、Istio以外のクライアントがIstio以外のサーバーと通信していることは問題です。一般的に、オペレーターはすべてのクライアントに同時にIstioサイドカーをインストールできないか、一部のクライアントでそうする権限がありません。サーバーにIstioサイドカーをインストールした後でも、既存の通信を中断することなく相互TLSを有効にすることはできません。

許可モードを有効にすると、サーバーはプレーンテキストトラフィックと相互TLSトラフィックの両方を許可します。このモードは、オンボーディングプロセスに高い柔軟性を提供します。サーバーにインストールされたIstioサイドカーは、既存のプレーンテキストトラフィックを中断することなく、すぐに相互TLSトラフィックを受け入れます。その結果、オペレーターは、クライアントのIstioサイドカーを徐々にインストールして構成し、相互TLSトラフィックを送信できます。クライアントの構成が完了したら、オペレーターはサーバーを相互TLSのみのモードに構成できます。詳細については、相互TLS移行チュートリアルをご覧ください。

セキュアネーミング

サーバーアイデンティティは証明書にエンコードされますが、サービス名はディスカバリサービスまたはDNSから取得されます。安全なネーミング情報は、サーバーアイデンティティをサービス名にマッピングします。アイデンティティAをサービス名Bにマッピングすることは、「AはサービスBを実行することを許可されています」という意味です。コントロールプレーンはapiserverを監視し、安全なネーミングマッピングを生成して、PEPに安全に配布します。次の例は、安全なネーミングが認証においてなぜ重要であるかを説明しています。

サービスdatastoreを実行する正当なサーバーは、infra-teamアイデンティティのみを使用するとします。悪意のあるユーザーは、test-teamアイデンティティの証明書とキーを持っています。悪意のあるユーザーは、クライアントから送信されたデータを検査するために、サービスになりすまそうとしています。悪意のあるユーザーは、test-teamアイデンティティの証明書とキーを使用して偽のサーバーを展開します。悪意のあるユーザーが（DNSスプーフィング、BGP/ルートハイジャック、ARPスプーフィングなどによって）datastoreに送信されたトラフィックをハイジャックし、偽のサーバーにリダイレクトしたとします。

クライアントがdatastoreサービスを呼び出すと、サーバーの証明書からtest-teamアイデンティティを抽出し、安全なネーミング情報を使用してtest-teamがdatastoreの実行を許可されているかどうかを確認します。クライアントは、test-teamがdatastoreサービスの実行を許可されていないことを検出し、認証は失敗します。

HTTP/HTTPS以外のトラフィックの場合、安全なネーミングはDNSスプーフィングから保護されません。この場合、攻撃者はサービスの宛先IPアドレスを変更します。TCPトラフィックにはHost情報が含まれておらず、Envoyはルーティングに宛先IPアドレスのみに依存できるため、EnvoyはハイジャックされたIPアドレス上のサービスにトラフィックをルーティングする可能性があります。このDNSスプーフィングは、クライアント側のEnvoyがトラフィックを受信する前でも発生する可能性があります。

認証アーキテクチャ

Istioメッシュ内でリクエストを受信するワークロードに対する認証要件は、ピア認証ポリシーとリクエスト認証ポリシーを使用して指定できます。メッシュオペレーターは、.yamlファイルを使用してポリシーを指定します。ポリシーは、デプロイされるとIstioの設定ストレージに保存されます。Istioコントローラーは設定ストレージを監視します。

ポリシーに変更があると、新しいポリシーはPEPに適切な認証メカニズムを実行する方法を指示する適切な設定に変換されます。コントロールプレーンは公開鍵を取得してJWT検証用の設定に添付する場合があります。または、IstiodはIstioシステムが管理するキーと証明書へのパスを提供し、それらをアプリケーションポッドにインストールして相互TLSを実現します。詳細はIDと証明書の管理セクションを参照してください。

Istioは、対象のエンドポイントに非同期的に設定を送信します。プロキシが設定を受信すると、新しい認証要件はそのポッドでただちに有効になります。

リクエストを送信するクライアントサービスは、必要な認証メカニズムに従う責任があります。リクエスト認証の場合、アプリケーションはJWTクレデンシャルを取得してリクエストに添付する責任があります。ピア認証の場合、Istioは2つのPEP間のすべてのトラフィックを自動的に相互TLSにアップグレードします。認証ポリシーで相互TLSモードが無効になっている場合、IstioはPEP間でプレーンテキストを引き続き使用します。この動作を上書きするには、デスティネーションルールを使用して相互TLSモードを明示的に無効にします。相互TLSの動作の詳細については、相互TLS認証セクションを参照してください。

Authentication Architecture
認証アーキテクチャ

Istioは、両方のタイプの認証によるIDと、該当する場合はクレデンシャル内のその他のクレームを次のレイヤー（認可）に出力します。

認証ポリシー

このセクションでは、Istio認証ポリシーの動作について詳しく説明します。アーキテクチャセクションで説明したように、認証ポリシーはサービスが受信するリクエストに適用されます。相互TLSでクライアント側の認証ルールを指定するには、DestinationRuleでTLSSettingsを指定する必要があります。詳細については、TLS設定リファレンスドキュメントを参照してください。

他のIstio設定と同様に、.yamlファイルで認証ポリシーを指定できます。kubectlを使用してポリシーをデプロイします。次の認証ポリシーの例では、app:reviewsラベルが付いたワークロードのトランスポート認証に相互TLSを使用する必要があることを指定しています。

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

ポリシースレージ

Istioは、メッシュスコープのポリシーをルートネームスペースに保存します。これらのポリシーには空のセレクターがあり、メッシュ内のすべてのワークロードに適用されます。ネームスペーススコープを持つポリシーは、対応するネームスペースに保存されます。これらは、それらのネームスペース内のワークロードのみに適用されます。selectorフィールドを設定した場合、認証ポリシーは設定した条件に一致するワークロードのみに適用されます。

ピア認証ポリシーとリクエスト認証ポリシーは、それぞれPeerAuthenticationとRequestAuthenticationという種類で個別に保存されます。

セレクターフィールド

ピア認証ポリシーとリクエスト認証ポリシーは、selectorフィールドを使用して、ポリシーが適用されるワークロードのラベルを指定します。次の例は、app:product-pageラベルを持つワークロードに適用されるポリシーのselectorフィールドを示しています。

selector:
  matchLabels:
    app: product-page

selectorフィールドに値を指定しない場合、Istioはポリシーのストレージスコープ内のすべてのワークロードにポリシーを一致させます。したがって、selectorフィールドはポリシーのスコープを指定するのに役立ちます。

  • メッシュ全体ポリシー：ルートネームスペースに指定され、selectorフィールドが空であるか、または存在しないポリシー。
  • ネームスペース全体ポリシー：ルート以外のネームスペースに指定され、selectorフィールドが空であるか、または存在しないポリシー。
  • ワークロード固有ポリシー：通常のネームスペースに定義され、空でないselectorフィールドを持つポリシー。

ピア認証ポリシーとリクエスト認証ポリシーは、selectorフィールドに関して同じ階層原則に従いますが、Istioはそれらをわずかに異なる方法で組み合わせ、適用します。

メッシュ全体ピア認証ポリシーは1つのみ、ネームスペース全体ピア認証ポリシーはネームスペースごとに1つのみ存在できます。同じメッシュまたはネームスペースに対して複数のメッシュ全体またはネームスペース全体のピア認証ポリシーを設定した場合、Istioは新しいポリシーを無視します。複数のワークロード固有のピア認証ポリシーが一致する場合、Istioは最も古いものを選択します。

Istioは、次の順序で、各ワークロードに対して最も狭い一致ポリシーを適用します。

  1. ワークロード固有
  2. ネームスペース全体
  3. メッシュ全体

Istioは、すべての一致するリクエスト認証ポリシーを、単一のリクエスト認証ポリシーから来たかのように組み合わせることができます。したがって、メッシュまたはネームスペースに複数のメッシュ全体またはネームスペース全体のポリシーを持つことができます。ただし、複数のメッシュ全体またはネームスペース全体のリクエスト認証ポリシーを持つことは避けることが依然として最善策です。

ピア認証

ピア認証ポリシーは、ターゲットワークロードでIstioが適用する相互TLSモードを指定します。サポートされているモードは次のとおりです。

  • PERMISSIVE：ワークロードは、相互TLSとプレーンテキストの両方のトラフィックを受け入れます。このモードは、サイドカーを使用できないワークロードが相互TLSを使用できない移行中に最も役立ちます。サイドカーインジェクションでワークロードが移行されたら、モードをSTRICTに変更する必要があります。
  • STRICT：ワークロードは相互TLSトラフィックのみを受け入れます。
  • DISABLE：相互TLSが無効になります。セキュリティの観点から、独自のセキュリティソリューションを提供しない限り、このモードを使用しないでください。

モードが設定されていない場合、親スコープのモードが継承されます。モードが設定されていないメッシュ全体ピア認証ポリシーは、デフォルトでPERMISSIVEモードを使用します。

次のピア認証ポリシーでは、fooネームスペース内のすべてのワークロードで相互TLSを使用する必要があります。

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

ワークロード固有のピア認証ポリシーを使用すると、異なるポートに対して異なる相互TLSモードを指定できます。ポート全体の相互TLS設定のためにワークロードがクレームしたポートのみを使用できます。次の例では、app:example-appワークロードのポート80で相互TLSを無効にし、他のすべてのポートにはネームスペース全体のピア認証ポリシーの相互TLS設定を使用します。

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

上記のピア認証ポリシーは、次のサービス設定によって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）を検証するために必要な値を指定します。これらには、次のものが含まれます。

  • リクエスト内のトークンの場所
  • 発行者またはリクエスト
  • 公開JSON Web Key Set（JWKS）

Istioは、提示されたトークン（提示されている場合）をリクエスト認証ポリシーのルールに対してチェックし、無効なトークンを持つリクエストを拒否します。リクエストにトークンが含まれていない場合、デフォルトで受け入れられます。トークンを含まないリクエストを拒否するには、特定の操作（パスやアクションなど）の制限を指定する認可ルールを提供します。

リクエスト認証ポリシーは、それぞれ一意の場所を使用する複数のJWTを指定できます。複数のポリシーがワークロードに一致する場合、Istioは、それらが単一のポリシーとして指定されているかのように、すべてのルールを組み合わせます。この動作は、異なるプロバイダーからのJWTを受け入れるようにワークロードをプログラムするのに役立ちます。ただし、複数の有効なJWTを持つリクエストは、そのようなリクエストの出力プリンシパルが未定義であるため、サポートされていません。

プリンシパル

ピア認証ポリシーと相互TLSを使用する場合、Istioはピア認証からIDをsource.principalに抽出します。同様に、リクエスト認証ポリシーを使用する場合、IstioはJWTからIDをrequest.auth.principalに割り当てます。これらのプリンシパルを使用して、認可ポリシーを設定し、テレメトリ出力として使用します。

認証ポリシーの更新

認証ポリシーはいつでも変更でき、Istioはほぼリアルタイムで新しいポリシーをワークロードにプッシュします。ただし、Istioはすべてのワークロードが同時に新しいポリシーを受信することを保証できません。次の推奨事項は、認証ポリシーの更新時の中断を回避するのに役立ちます。

  • モードをDISABLEからSTRICT、またはその逆に変更する場合は、PERMISSIVEモードを使用して中間ピア認証ポリシーを使用します。すべてのワークロードが目的のモードに正常に切り替わったら、最終モードでポリシーを適用できます。Istioテレメトリを使用して、ワークロードが正常に切り替わったことを確認できます。
  • リクエスト認証ポリシーをあるJWTから別のJWTに移行する場合は、古いルールを削除せずに新しいJWTのルールをポリシーに追加します。その後、ワークロードは両方のタイプのJWTを受け入れ、すべてのトラフィックが新しいJWTに切り替わったら、古いルールを削除できます。ただし、各JWTは異なる場所を使用する必要があります。

認可

Istioの認可機能は、メッシュ内のワークロードに対して、メッシュ全体、ネームスペース全体、およびワークロード全体のアクセス制御を提供します。このレベルの制御により、次の利点が得られます。

  • ワークロード間およびエンドユーザーからワークロードへの認可。
  • シンプルなAPI：使いやすく保守しやすい単一のAuthorizationPolicy CRDが含まれています。
  • 柔軟なセマンティクス：オペレーターはIstio属性に関するカスタム条件を定義し、CUSTOM、DENY、ALLOWアクションを使用できます。
  • 高性能：Istio認可（ALLOWとDENY）は、Envoyでネイティブに適用されます。
  • 高い互換性：gRPC、HTTP、HTTPS、HTTP/2をネイティブにサポートし、プレーンTCPプロトコルもサポートします。

認可アーキテクチャ

認可ポリシーは、サーバー側のEnvoyプロキシのインバウンドトラフィックへのアクセス制御を適用します。各Envoyプロキシは、実行時にリクエストを認可する認可エンジンを実行します。リクエストがプロキシに届くと、認可エンジンは現在の認可ポリシーに対してリクエストコンテキストを評価し、ALLOWまたはDENYの認可結果を返します。オペレーターは、.yamlファイルを使用してIstio認可ポリシーを指定します。

Authorization Architecture
認可アーキテクチャ

暗黙的な有効化

Istioの認可機能を明示的に有効にする必要はありません。インストール後に使用できます。ワークロードへのアクセス制御を適用するには、認可ポリシーを適用します。

認可ポリシーが適用されていないワークロードの場合、Istioはすべてのリクエストを許可します。

認可ポリシーは、ALLOW、DENY、CUSTOMアクションをサポートします。必要に応じて、それぞれ異なるアクションを持つ複数のポリシーを適用して、ワークロードへのアクセスを保護できます。

Istioは、CUSTOM、DENY、ALLOWの順序でレイヤーで一致するポリシーをチェックします。各アクションの種類について、Istioは最初にアクションが適用されたポリシーが存在するかどうかを確認し、次にリクエストがポリシーの仕様に一致するかどうかを確認します。リクエストがレイヤーのいずれかのポリシーに一致しない場合、チェックは次のレイヤーに続きます。

次のグラフは、ポリシーの優先順位を詳細に示しています。

Authorization Policy Precedence
認可ポリシーの優先順位

複数の認可ポリシーを同じワークロードに適用する場合、Istioはそれらを加算的に適用します。

認可ポリシー

承認ポリシーを設定するには、AuthorizationPolicyカスタムリソースを作成します。承認ポリシーには、セレクター、アクション、およびルールのリストが含まれています。

  • selectorフィールドは、ポリシーの対象を指定します。
  • actionフィールドは、リクエストを許可するか拒否するかを指定します。
  • rulesは、アクションをトリガーするタイミングを指定します。
    • rules内のfromフィールドは、リクエストの送信元を指定します。
    • rules内のtoフィールドは、リクエストの操作を指定します。
    • whenフィールドは、ルールを適用するために必要な条件を指定します。

次の例は、有効なJWTトークンを持つリクエストが送信された場合、cluster.local/ns/default/sa/curlサービスアカウントとdev名前空間という2つの送信元が、foo名前空間内のapp: httpbinおよびversion: v1ラベルを持つワークロードにアクセスすることを許可する承認ポリシーを示しています。

apiVersion: security.istio.io/v1
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/curl"]
   - source:
       namespaces: ["dev"]
   to:
   - operation:
       methods: ["GET"]
   when:
   - key: request.auth.claims[iss]
     values: ["https://#"]

次の例は、送信元がfoo名前空間でない場合にリクエストを拒否する承認ポリシーを示しています。

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

拒否ポリシーは許可ポリシーよりも優先されます。許可ポリシーに一致するリクエストは、拒否ポリシーにも一致する場合、拒否される可能性があります。Istioは、許可ポリシーが拒否ポリシーをバイパスできないように、最初に拒否ポリシーを評価します。

ポリシートーゲット

metadata/namespaceフィールドとオプションのselectorフィールドを使用して、ポリシーのスコープまたはターゲットを指定できます。ポリシーは、metadata/namespaceフィールドの名前空間に適用されます。ルート名前空間に設定した場合、ポリシーはメッシュ内のすべて名前空間に適用されます。ルート名前空間の値は設定可能であり、デフォルトはistio-systemです。他の名前空間に設定した場合、ポリシーは指定された名前空間のみに適用されます。

selectorフィールドを使用して、特定のワークロードに適用されるポリシーをさらに制限できます。selectorは、ラベルを使用してターゲットワークロードを選択します。セレクターには、{key: value}ペアのリストが含まれ、keyはラベルの名前です。設定されていない場合、承認ポリシーは、承認ポリシーと同じ名前空間内のすべてのワークロードに適用されます。

たとえば、allow-readポリシーは、default名前空間内のapp: productsラベルを持つワークロードへの"GET"と"HEAD"アクセスを許可します。

apiVersion: security.istio.io/v1
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フィールド
  • sourceセクション下のipBlocks
  • toセクション下のportsフィールド

次のポリシーの例では、/test/*プレフィックスまたは*/infoサフィックスを持つパスへのアクセスを許可します。

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

除外の一致

whenフィールドのnotValues、sourceフィールドのnotIpBlocks、toフィールドのnotPortsなど、否定的な条件に一致させるために、Istioは除外マッチングをサポートしています。次の例では、リクエストパスが/healthzでない場合、JWT認証から導出される有効なリクエストプリンシパルが必要です。したがって、このポリシーは/healthzパスへのリクエストをJWT認証から除外します。

apiVersion: security.istio.io/v1
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/v1
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-nothing、deny-all、allow-allポリシー

次の例は、何も一致しないALLOWポリシーを示しています。他のALLOWポリシーがない場合、「デフォルト拒否」の動作により、リクエストは常に拒否されます。

「デフォルト拒否」の動作は、ワークロードにALLOWアクションを持つ承認ポリシーが少なくとも1つ存在する場合にのみ適用されます。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
spec:
  action: ALLOW
  # the rules field is not specified, and the policy will never match.

次の例は、すべてのアクセスを明示的に拒否するDENYポリシーを示しています。DENYポリシーはALLOWポリシーよりも優先されるため、リクエストを許可する別のALLOWポリシーが存在する場合でも、常にリクエストを拒否します。これは、ワークロードへのすべてのアクセスを一時的に無効にしたい場合に便利です。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
spec:
  action: DENY
  # the rules field has an empty rule, and the policy will always match.
  rules:
  - {}

次の例は、ワークロードへのフルアクセスを許可するALLOWポリシーを示しています。これは常にリクエストを許可するため、他のALLOWポリシーは無効になります。ワークロードへのフルアクセスを一時的に公開したい場合に便利です。ただし、CUSTOMおよびDENYポリシーにより、リクエストが拒否される可能性があります。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-all
spec:
  action: ALLOW
  # This matches everything.
  rules:
  - {}

カスタム条件

whenセクションを使用して、追加の条件を指定することもできます。たとえば、次のAuthorizationPolicy定義には、request.headers[version]が"v1"または"v2"であるという条件が含まれています。この場合、キーはrequest.headers[version]であり、これはIstio属性request.headers（マップ）のエントリです。

apiVersion: security.istio.io/v1
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/curl"]
   to:
   - operation:
       methods: ["GET"]
   when:
   - key: request.headers[version]
     values: ["v1", "v2"]

条件のサポートされているkey値は、条件ページに記載されています。

認証済みおよび未認証のアイデンティティ

ワークロードを公開アクセス可能にするには、sourceセクションを空のままにする必要があります。これにより、すべての（認証済みと未認証の両方）ユーザーとワークロードからの送信元が許可されます。

apiVersion: security.istio.io/v1
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/v1
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"]

プレーンTCPプロトコルでのIstio認可の使用

Istioの承認は、MongoDBなどのプレーンTCPプロトコルを使用するワークロードをサポートしています。この場合、HTTPワークロードの場合と同じように承認ポリシーを設定します。違いは、特定のフィールドと条件がHTTPワークロードのみに適用されることです。これらのフィールドには以下が含まれます。

  • 承認ポリシーオブジェクトの送信元セクションのrequest_principalsフィールド
  • 承認ポリシーオブジェクトの操作セクションのhosts、methods、pathsフィールド

サポートされている条件は、条件ページにリストされています。TCPワークロードにHTTP専用のフィールドを使用する場合、Istioは承認ポリシー内のHTTP専用のフィールドを無視します。

ポート27017でMongoDBサービスがあると仮定すると、次の例では、Istioメッシュ内のbookinfo-ratings-v2サービスのみがMongoDBワークロードにアクセスすることを許可する承認ポリシーを設定します。

apiVersion: security.istio.io/v1
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"]

相互TLSへの依存

Istioは相互TLSを使用して、クライアントからサーバーに安全に情報を渡します。承認ポリシーで次のフィールドを使用する前に、相互TLSを有効にする必要があります。

  • sourceセクション下のprincipalsおよびnotPrincipalsフィールド
  • sourceセクション下のnamespacesおよびnotNamespacesフィールド
  • source.principalカスタム条件
  • source.namespaceカスタム条件

プレーンテキストトラフィックが許可型の相互TLSモードで使用されている場合、予期しないリクエストの拒否やポリシーのバイパスを防ぐために、常に厳格な相互TLSモードでこれらのフィールドを使用することを強くお勧めします。

厳格な相互TLSモードを有効にできない場合の詳細と代替手段については、セキュリティアドバイザリを確認してください。

詳細はこちら

基本的な概念を学習した後、さらにレビューするリソースがあります。

  • 認証と承認のタスクに従って、セキュリティポリシーを試してください。

  • メッシュのセキュリティを向上させるために使用できるセキュリティポリシーの例をいくつか学習してください。

  • 問題が発生したときにセキュリティポリシーの問題をより適切にトラブルシューティングするために、一般的な問題を読んでください。

この情報は役に立ちましたか？
改善のための提案はありますか？

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