© Hitachi, Ltd. 2022. All rights reserved. Istioを活用したセキュアなマイクロサービスの実現: アプリ透過型のユーザ及びサービス間の認証認可 CloudNative Security Conference 2022 株式会社 日立製作所 研究開発グループ サービスコンピューティング研究部 井出 貴也

© Hitachi, Ltd. 2022. All rights reserved. 内容 1. マイクロサービスのセキュリティ戦略 ◇ マイクロサービスの概要 ◇ NIST SP800-204の整理 2. Istioの認証認可機能 ◇ サービス間認証 ◇ ユーザ認証 ◇ 認可制御 ◇ 外部認可制御、およびツール連携の検証 ◇ その他セキュリティプラクティス 1

© Hitachi, Ltd. 2022. All rights reserved. マイクロサービスのセキュリティ戦略 2

© Hitachi, Ltd. 2022. All rights reserved. マイクロサービスアーキテクチャ ▪ 複数の小さなサービスを通信で連携させることでシステムを構成する設計方式 ▪ サービスごとに小さなチームが存在し、自律的に開発・運用 ▪ 利点：各サービスの独立性が高い ◇ 変更しやすい ◇ 仕様の自由度が高い ◇ スケーリングしやすい ◇ サービスを増やすことで 開発規模を広げやすい 3 マイクロサービスアーキテクチャ型のシステム UI 決済 商品 推薦 発注 商品 管理 ユーザ 管理 注文 管理

© Hitachi, Ltd. 2022. All rights reserved. マイクロサービスの成長 ▪ ビジネスの成長に伴いシステムは大きくなる ◇ サービスやサービスチームの増加 ◇ それぞれのサービスが随時変化していく ◇ サービスの開発言語や品質も様々 4

© Hitachi, Ltd. 2022. All rights reserved. マイクロサービスのセキュリティ ▪ 無数のサービスやその構成要素が存在 ◇ 防御すべき対象が多い ◇ 個別に管理していてはミスが起きうる ▪ それらが通信を介して複雑に連携 ◇ セキュアな通信 ◇ 細やかなアクセス制御 ▪ 多様なサービスが日々それぞれ変化していく ◇ 個々の仕様に依存した作りは困難 → 何か指針はないか 5

© Hitachi, Ltd. 2022. All rights reserved. NIST SP 800-204 Security Strategies for Microservices-based Application Systems ▪ マイクロサービスに向けたセキュリティガイダンス ▪ 米国標準技術研究所が作成 ▪ サービスメッシュを活用するアプローチ ▪ Istio Up and Runningの著者である Zack Butcher氏が執筆に参画 6 画像引用元: https://csrc.nist.gov/publications/detail/sp/800-204/final

© Hitachi, Ltd. 2022. All rights reserved. ▪ NIST SP800-204は4個の文書で構成 ▪ 本セッションは 204、204A、204B を対象とする NIST SP800-204シリーズ概略 7 NIST SP800- タイトル 概要 204 Microservices-based application systems マイクロサービスの特徴やセキュリティ要件、 要件を満たすための戦略の整理 204A Building secure microservices-based applications using service-mesh architecture サービスメッシュの背景や マイクロサービスに対するセキュリティ要件 204B Attribute-based Access Control for Microservices-based Applications Using a Service Mesh サービス間の相互認証および 属性ベースアクセス制御(ABAC)による認可制御 204C Implementation of DevSecOps for a Microservices-based Application with Service Mesh CI/CDパイプラインにてシステムに セキュリティを付与するための設計

© Hitachi, Ltd. 2022. All rights reserved. 各サービスの前段にプロキシを配置し、そのプロキシを Control Planeにて制御するネットワークモデル 嬉しさ ▪ 個々のサービスからは透過的に ▪ システム全体で均一な各種機能を ▪ サービスに付与する 主要機能 ▪ トラフィック制御 ▪ 認証・認可 ▪ 監視 サービスメッシュとは 8 Svc1 Svc4 UI Svc2 Svc3 Control Plane サービスメッシュ Control サービスの端点で あるプロキシを制 御することで、サー ビス間通 信を 自 由に制御できる

© Hitachi, Ltd. 2022. All rights reserved. サービスメッシュのプロキシは各サービスの通信にセキュリティポリシーを強制させる PEP(Policy Enforcement Point: ポリシー施工点)として機能する セキュリティ観点でのサービスメッシュへの期待 9 Control Plane ポリシー付与 Proxy Svc1 Proxy Svc2 暗号化された 通信 通信暗号化 宛先の認証 送信元の認証 アクセス制御 アクセスログ出力 メトリクス出力

© Hitachi, Ltd. 2022. All rights reserved. マイクロサービスの階層とセキュリティのスコープ ▪ NIST SP 800-204はマイクロサービスに対する脅威を6階層で整理 ▪ マイクロサービス特有の脅威である ネットワーク層 に焦点をあてて議論 10 階層 概要 参考 サービス・アプリ アプリケーションコード NIST SP 800-180, 同190 ネットワーク マイクロサービス内外の通信 同204 オーケストレーション VM・コンテナのオーケストレーション(e.g., K8s) 同180 クラウド環境 クラウド内設備 同210、同144 仮想化 ハイパーバイザ、コンテナベースイメージ 同125、同180 ハードウェア 物理マシン、物理ネットワーク －

© Hitachi, Ltd. 2022. All rights reserved. セキュリティ戦略の観点 ▪ NIST SP800-204では、セキュリティ戦略に2種の観点が見られる ▪ 本セッションでは、サービスメッシュ利用時のセキュリティ要件 に絞って議論する※1 11 サービスメッシュが持つべき セキュリティ機能仕様 サービスメッシュ利用時の セキュリティ要件 • サービス発見の仕様 • 認可の粒度 • IDの一貫性 など ※1 なお、後述のIstioは大部分の要件を満たす（アプリレイヤの攻撃検知などは未対応） セキュリティ戦略の観点 ↑ 本セッションの対象

© Hitachi, Ltd. 2022. All rights reserved. マイクロサービスのセキュリティ戦略 サービスメッシュ利用者の視点では、ネットワーク層のセキュリティ戦略は大きく4種に分類 12 Svc4 Svc3 Svc2 Svc1 UI Microservices Ingress/ Egress

© Hitachi, Ltd. 2022. All rights reserved. マイクロサービスのセキュリティ戦略 サービスメッシュ利用者の視点では、ネットワーク層のセキュリティ戦略は大きく4種に分類 13 Svc4 Svc3 Svc2 Svc1 UI Microservices Ingress/ Egress サービス間認証 ユーザ認証 アクセス(認可)制御 通信暗号化 Ingress/Egress 通信管理 通信の保護と 認証・認可

© Hitachi, Ltd. 2022. All rights reserved. ロード・バランシング 流量制御 リトライ制御 タイムアウト サーキットブレーカー 耐障害性と 回復力の向上 Client マイクロサービスのセキュリティ戦略 サービスメッシュ利用者の視点では、ネットワーク層のセキュリティ戦略は大きく4種に分類 14 Svc4 Svc3 Svc2 Svc1 UI Microservices Ingress/ Egress サービス間認証 ユーザ認証 アクセス(認可)制御 通信暗号化 Ingress/Egress 通信管理 通信の保護と 認証・認可

© Hitachi, Ltd. 2022. All rights reserved. トレース収集 ログ収集 メトリクス収集 セキュリティ 監視 Monitoring ロード・バランシング 流量制御 リトライ制御 タイムアウト サーキットブレーカー 耐障害性と 回復力の向上 Client マイクロサービスのセキュリティ戦略 サービスメッシュ利用者の視点では、ネットワーク層のセキュリティ戦略は大きく4種に分類 15 Svc4 Svc3 Svc2 Svc1 UI Microservices Ingress/ Egress サービス間認証 ユーザ認証 アクセス(認可)制御 通信暗号化 Ingress/Egress 通信管理 通信の保護と 認証・認可

© Hitachi, Ltd. 2022. All rights reserved. トレース収集 ログ収集 メトリクス収集 セキュリティ 監視 Monitoring ロード・バランシング 流量制御 リトライ制御 タイムアウト サーキットブレーカー 耐障害性と 回復力の向上 Client 権限の 最小化 コンテナ特権排除 サービスメッシュ操作 権限の限定化 マイクロサービスのセキュリティ戦略 サービスメッシュ利用者の視点では、ネットワーク層のセキュリティ戦略は大きく4種に分類 16 Svc4 Svc3 Svc2 Svc1 UI Microservices Ingress/ Egress サービス間認証 ユーザ認証 アクセス(認可)制御 通信暗号化 Ingress/Egress 通信管理 通信の保護と 認証・認可

© Hitachi, Ltd. 2022. All rights reserved. セキュリティ戦略一覧 17 分類 目的 セキュリティ戦略 概要 通信の保護と 認証・認可 不正アクセス防止 通信暗号化 TLSを用いて通信が暗号化されている サービス間認証 マイクロサービスのインスタンス同士が相互に正当性を確認し合う ユーザ認証 検証可能なトークンを用い、ユーザの正当性を確認する アクセス(認可)制御 トラフィックの属性に基づきサービスへのアクセス可否を判断する Ingress/Egress通信管理 外部からの流入・流出トラフィックを管理する 回復力と 耐障害性 可用性の担保 ロードバランサー 死活監視と連携させ、トラフィックの負荷を複数インスタンスに分散 流量制御 アプリとインフラの要件に基づき単位時間あたりアクセス上限を設ける サーキットブレーカー 障害中のインスタンスへのアクセスを遮断し、障害の波及を抑止する リトライ・タイムアウト エラー時のリトライ制御とハングアップ時のタイムアウトを設ける セキュリティ監視 攻撃の検知 メトリクス収集 スループット、エラー率、レイテンシをベースライン監視する ログ収集 エラーやクラッシュ時のログ・ダンプを確保する トレース収集 複数インスタンスを跨ぐリクエストのトランザクションを確保する 権限の最小化 被害局所化 コンテナの特権排除 Rootユーザやsudoの利用などを禁止する サービスメッシュ操作権の限定化 操作権限をサービス単位やNamespace単位で払い出す 以降、分類ごとに要点をピックアップ

© Hitachi, Ltd. 2022. All rights reserved. 通信の保護と認証・認可 通信の保護 ▪ 外界からの分離(Ingress/Egressゲートウェイ)および暗号化にて担保 ▪ ゲートウェイはFirewallによるアクセス制御との連携容易化の側面もある 認証(正当性チェック) ▪ サービス間認証 : 送信元と宛先が互いに証明書で認証しあう mTLS にて通信を暗号化 ◇ デフォルトで mTLS を用いる ◇ 証明書は定期的に更新する。数時間オーダーが望ましい ◇ 証明書の発行には企業の認証局を用いると良い(監査・失効を集約できる) ▪ ユーザ認証 : JWTなどのデジタル署名付きトークンを用い、外部からのリクエストを認証する ◇ トークンの有効期限を短くする。これがセッションの持続時間となる ◇ 認可システムへの通信もサービス間認証で保護する ◇ ユーザからのリクエストは全てログを生成し、認証・認可のポリシー反映を確かにする 18 通信の保護と 認証・認可

© Hitachi, Ltd. 2022. All rights reserved. 通信の保護と認証・認可 認可(アクセス可否の判定) ▪ ABAC(属性ベースアクセス制御)を活用する ▪ 認証されていない通信は全て拒否する ▪ 外部へのアクセスもデフォルト無効とする ▪ 通信はNamespaceの範囲に制限し、Namespaceを超える通信は 明示的なポリシーによってのみ許可する (参考) ABAC ▪ 属性情報を論理式(ポリシー)で評価するアクセス制御方式 ▪ 属性情報はSubject(要求元)、Resource(アクセス先)、Property(環境情報)からなる ▪ きめ細かいアクセス制御や拡張性に優れる ▪ 一方、設計と実装は複雑 19 通信の保護と 認証・認可

© Hitachi, Ltd. 2022. All rights reserved. 耐障害性と回復力の向上 負荷分散 ▪ 過負荷による応答遅延や障害回避のため、各サービスは複数インスタンスで構成する ▪ ロードバランサとマイクロサービス間の通信を保護する ▪ ヘルスチェックと連携する （Istioの場合、KubernetesのReadiness Probeをきちんと設定する） 流量制御 ▪ 時間あたりのアクセス上限を設ける ▪ サービスとインフラ両方の要件に基づいて値を決める ▪ クライアント別、全クライアント合計でそれぞれ上限を設けることが望ましい 20 耐障害性と 回復力の向上

© Hitachi, Ltd. 2022. All rights reserved. セキュリティ監視 メトリクス ▪ インスタンスごとにスループット、エラーレート、レイテンシの値を取得 ▪ 正常時のベースラインを確立し、その逸脱を検知可能にする ▪ セントラルダッシュボードにサービスやネットワークの状態を表示する ▪ (上記メトリクスはSLO策定などにも活用できる) ログ ▪ IPアドレス、認証ID、時刻、HTTPメソッド、URI、ステータスコード、レスポンスサイズ (Common Log Format)のパタメータはアクセスログに必要となる ▪ メッセージとしてマイクロサービス名、トレースID等を含めると良い。機密情報はマスキングする ▪ Validationエラーや不要なパラメータに起因するエラー、クラッシュ、コアダンプをログに記録する 21 セキュリティ 監視

© Hitachi, Ltd. 2022. All rights reserved. 権限の最小化 サービスメッシュの管理操作 ▪ サービスやNamespaceの単位で払い出す ▪ Istioは以下の権限にも注意 ◇ 外部アクセスに関わるGatewayやServiceEntryリソースの操作 ◇ 全Namespaceにポリシーが反映されるistio-system Namespaceへのデプロイ権限 コンテナの権限 ▪ rootユーザの利用および特権昇格の禁止 ▪ hostPathボリュームの利用禁止 (リソース管理を阻害) ▪ コンテナのファイルシステムはデフォルトRead Onlyとし、 データベースなどの書き込みが必須なコンテナのみ ReadWriteの設定で上書きする 22 権限の 最小化

© Hitachi, Ltd. 2022. All rights reserved. プラクティス 全体を通し、以下プラクティスを重視していることが伺える Secure by Default ▪ 利用者が知らなくとも標準でセキュアになるよう設計すること ▪ サービス間通信はデフォルトでmTLSを用いる ▪ Namespace外の通信はデフォルトで拒否 ▪ （ただし、縛りすぎると開発速度に影響） Principle of Least Privilege ▪ 必要最小限の権限だけを付与する ▪ サービス間のアクセス制御 ▪ サービスメッシュ操作権限 ▪ コンテナの権限 23

© Hitachi, Ltd. 2022. All rights reserved. セキュリティ戦略一覧（再掲） 24 カテゴリ 目的 セキュリティ戦略 概要 通信の保護と 認証・認可 不正アクセス防止 通信暗号化 TLSを用いて通信が暗号化されている サービス間認証 マイクロサービスのインスタンス同士が相互に正当性を確認し合う ユーザ認証 検証可能なトークンを用い、ユーザの正当性を確認する アクセス(認可)制御 トラフィックの属性に基づきサービスへのアクセス可否を判断する Ingress/Egress通信管理 外部からの流入・流出トラフィックを管理する 回復力と 耐障害性 攻撃時の 可用性担保 ロードバランサー 死活監視と連携させ、トラフィックの負荷を複数インスタンスに分散 流量制御 アプリとインフラの要件に基づき単位時間あたりアクセス上限を設ける サーキットブレーカー 障害中のインスタンスへのアクセスを遮断し、障害の波及を抑止する リトライ・タイムアウト エラー時のリトライ制御とハングアップ時のタイムアウトでロバストにする セキュリティ監視 攻撃の検知 メトリクス収集 トラフィック量、エラー率、レイテンシをベースライン監視する ログ収集 エラーやクラッシュ時のログ・ダンプを確保する トレース収集 複数インスタンスを跨ぐリクエストのトランザクションを確保する 権限の最小化 被害局所化 コンテナの特権排除 Rootユーザやsudoの利用などを禁止する サービスメッシュ操作権の限定化 操作権限をサービス単位やNamespace単位で払い出す

© Hitachi, Ltd. 2022. All rights reserved. セキュリティ戦略一覧（再掲） 25 カテゴリ 目的 セキュリティ戦略 概要 通信の保護と 認証・認可 不正アクセス防止 通信暗号化 TLSを用いて通信が暗号化されている サービス間認証 マイクロサービスのインスタンス同士が相互に正当性を確認し合う ユーザ認証 検証可能なトークンを用い、ユーザの正当性を確認する アクセス(認可)制御 トラフィックの属性に基づきサービスへのアクセス可否を判断する Ingress/Egress通信管理 外部からの流入・流出トラフィックを管理する 回復力と 耐障害性 攻撃時の 可用性担保 ロードバランサー 死活監視と連携させ、トラフィックの負荷を複数インスタンスに分散 流量制御 アプリとインフラの要件に基づき単位時間あたりアクセス上限を設ける サーキットブレーカー 障害中のインスタンスへのアクセスを遮断し、障害の波及を抑止する リトライ・タイムアウト エラー時のリトライ制御とハングアップ時のタイムアウトでロバストにする セキュリティ監視 攻撃の検知 メトリクス収集 トラフィック量、エラー率、レイテンシをベースライン監視する ログ収集 エラーやクラッシュ時のログ・ダンプを確保する トレース収集 複数インスタンスを跨ぐリクエストのトランザクションを確保する 権限の最小化 被害局所化 コンテナの特権排除 Rootユーザやsudoの利用などを禁止する サービスメッシュ操作権の限定化 操作権限をサービス単位やNamespace単位で払い出す 以降のスコープ

© Hitachi, Ltd. 2022. All rights reserved. Istioの認証認可機能 26

© Hitachi, Ltd. 2022. All rights reserved. Istio概要 https://github.com/istio/istio Istio ▪ Google、RedHat、IBMが主導するOSSのサービスメッシュ ▪ 高機能, 高い知名度 ◇ 機能比較: Service Mesh Comparison (INNOQ) ◇ CNCF Micro Surveyでの利用者ランキング2位 ▪ Kubernetes上で動作 ◇ Custom Resourceとしてポリシーをデプロイ ▪ マネージドサービスも存在 ◇ OpenShift ServiceMesh ◇ Anthos ServiceMesh ◇ Tanzu ServiceMesh(Istio互換) 27

© Hitachi, Ltd. 2022. All rights reserved. Istioの機能 28 トラフィック管理 セキュリティ オブザーバビリティ クラスタ延伸 Routing, Mirroring, Splitting, Rate Limit, Timeout, Retry, CORS, Fault Injection, etc. mTLS, Peer authn/authz, Request authn/authz, External authz Monitoring, Logging, Distributed Tracing, Service Map Multiple-K8s Integration, VM Expansion

© Hitachi, Ltd. 2022. All rights reserved. Istioの認証認可 認証機能 ▪ サービス間認証 : mTLSにより通信するPodが相互に正当性を確認 ▪ ユーザ認証 : リクエスト内のトークン(JWT)を用い、ユーザの正当性を確認 認可機能 ▪ 認可 : トラフィック情報に基づくABAC ▪ 外部認可 : 外部ツールを用いた認証認可。 Open Policy Agent連携など 以下、それぞれ見ていく 29

© Hitachi, Ltd. 2022. All rights reserved. サービス間認証 ▪ 非常に強力、かつ通常時は意識しなくて良い ▪ PeerAuthenticationリソースにて操作 ▪ モード ◇ PERMISSIVE : mTLSも平文も受信 (デフォルト) ◇ STRICT : mTLSのみ受信 (推奨設定) ◇ DISABLE : mTLS不使用 ◇ UNSET : 上位設定を引き継ぐ ▪ STRICT 適用時は監視やIstio外通信などのエラーに注意 ◇ ポート単位のモード変更(portLevelMtls)などを活用 ## 全プロキシを mTLS 以外受け付けなくさせる apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: mtls-strict-all ## istio-systemにデプロイすると全Namespaceに適用 namespace: istio-system spec: mtls: mode: STRICT --- ## accessTo:legacy ラベルが付いたプロキシのみ平文を許容 apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: "access-to-legacy" namespace: default spec: selector: matchLabels: accessTo: legacy mtls: mode: PERMISSIVE mTLSを用い、送信・受信側双方のPodが互いを 認証を行う機能。デフォルトで有効化されている 30

© Hitachi, Ltd. 2022. All rights reserved. サービス間認証のID ▪ Istioは認証時にSPIFFE IDを用いる ◇ SPIFFE IDはX.509証明書のSANフィールドに格納される ▪ SPIFFE IDには Service Account および Namespace が埋め込まれる ◇ これら値は認可制御の属性として利用できる ◇ このため、特定のPodのみアクセス可否を変更する場合、 Service Accountの変更が有効 31 spiffe:///ns//sa/ #例 spiffe://cluster.local/ns/default/sa/myaccount IstioのSPIFFE ID

© Hitachi, Ltd. 2022. All rights reserved. サービス間認証における外部認証局の利用 ▪ Istioは企業が元々保有している認証局を利用可能 ◇ NIST SP800-204における推奨事項 ▪ 認証局を指定するには、istio-system Namespaceに各種証明書をまとめた cacerts Secretリソースを作成し、その後にIstioをデプロイする ▪ 本番環境では、Vault 等を用いたSecret保護が推奨 32 $ kubectl create namespace istio-system $ kubectl create secret generic cacerts -n istio-system / --from-file=./mycert/ca-cert.pem / # 中間証明書 --from-file=./mycert/ca-key.pem / # 中間キー --from-file=./mycert/root-cert.pem / # ルート証明書 --from-file=./mycert/cert-chain.pem # 証明書チェーン $ istioctl install 外部認証局の利用

© Hitachi, Ltd. 2022. All rights reserved. ユーザ認証 ▪ RequestAuthenticationリソースにて設定 ▪ ただし、JWT取得自体はスコープ外 ◇ JWTの取得はサービス側で行うか 後述の外部認可機能を使う ▪ RequestAuthenticationを設定していても JWTを含まないリクエストには適用されない →別途AuthrizationPolicyにて JWTの値を含むか確認要(右例下) ## foo.com にて JWT を検証する apiVersion: security.istio.io/v1beta1 kind: RequestAuthentication metadata: name: httpbin spec: selector: matchLabels: app: httpbin jwtRules: - issuer: https://foo.com # jwtの発行者(issと一致させる) jwksUri: https://foo.com/.well-known/jwks.json # 検証先 forwardOriginalToken: true # jwtを転送するか --- ## jwtのIDが存在する通信のみ通過 apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: httpbin spec: selector: matchLabels: app: httpbin rules: - from: - source: requestPrincipals: ["*"] # jwt内のIDが存在する 33 リクエスト内トークン(JWT)の正当性を 外部Issuerに問い合わせて検証する

© Hitachi, Ltd. 2022. All rights reserved. ## User Serviceまたは監視系からのアクセスのみ許可する apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: user-db-allow-only-user-service namespace: default spec: selector: matchLabels: name: user-db action: ALLOW rules: # user ServiceAccountからの任意アクセスを許可 - from: - source: principals: - "cluster.local/ns/default/sa/user" # メトリクス収集のため、監視系へのGETリクエストは一様に許可 - to: - operation: methods: ["GET"] ports: ["15020"] # メトリクス出力ポート 認可(1/2) ▪ AuthorizationPolicyリソースで操作 ▪ 送信元(from)、宛先(to)、条件(when) にて トラフィックを指定 ▪ 指定したトラフィックにALLOW, DENY, AUDIT, CUSTOMのアクションを指定 ◇ AUDITは現状stackdriver pluginが必要 ◇ CUSTOMは外部認可用 ▪ デフォルトはAllow All ◇ ただし、action: ALLOWのリソースをデプロイすると、 それ以外はDenyと判定されるようになる 34 トラフィック情報に基づく 属性ベースアクセスコントロール

© Hitachi, Ltd. 2022. All rights reserved. 認可(2/2) ▪ from.source ◇ ID(SPIFEE or JWT)、Namespaces、 IPブロック、RemoteIPブロックを指定可能 ◇ NamespaceとSPIFEE ID(principal)は mTLS化されてなければ取得できない ◇ JWTは "/_{" のフォーマット ▪ to.operation ◇ Host、Port、HTTPメソッド、Path を指定可能 ▪ when ◇ JWT内パラメータやSNI、HTTPヘッダ、 envoy.filtersを指定可能 ◇ fromやtoと同じパラメータも指定できるが、 fromやtoにて設定した方が見通しが良い ## User Serviceまたは監視系からのアクセスのみ許可する apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: user-db-allow-only-user-service namespace: default spec: selector: matchLabels: name: user-db action: ALLOW rules: # user ServiceAccountからの任意アクセスを許可 - from: - source: principals: - "cluster.local/ns/default/sa/user" # メトリクス収集のため、監視系へのGETリクエストは一様に許可 - to: - operation: methods: ["GET"] ports: ["15020"] # メトリクス出力ポート 35}

© Hitachi, Ltd. 2022. All rights reserved. ここまでの認証認可のサンプル Deny All (rulesがないためALLOWにマッチしない→DENY判定) 36 apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: deny-all namespace: default spec: {} Namespace外通信の遮断 apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: strict-all namespace: default spec: mtls: mode: STRICT --- apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: ns-isolation namespace: default spec: action: ALLOW rules: - from: - source: #namespaces指定はmTLSが前提 namespaces: ["default"] apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: allow-all namespace: default spec: rules: [{}] # action:ALLOWに無条件マッチ Allow Alll (無条件でALLOWにマッチ)

© Hitachi, Ltd. 2022. All rights reserved. 外部認可 ▪ リクエストのアクセス可否を外部認可ツールに問い合わせる ▪ 外部認可ツールは ALLOW / DENY を返す ▪ リクエストのたびに問い合わせる。レイテンシ増に注意 37 Proxy Svc2 Open Policy Agent トラフィック アイコン引用元: https://cncf-branding.netlify.app/projects/opa/ User 外部認可 ALLOW or DENY Svc1 Service

© Hitachi, Ltd. 2022. All rights reserved. 外部認可の設定 ▪ 2通りの設定方法あり ◇ Extension Providerが新しい方法だが、Istio全体設定に手を入れる必要あり ◇ トラフィックの対象がシンプル → EnvoyFilter が容易 ◇ 対象トラフィックを細かく制御 → IstioOperator で Extension Provider定義 38 方式 概要 利点 問題点 Extension Provider定義 meshConfigもしくはIstioOperator リソースにてExtension Providerを定義。 AuthrizationPolicyのCUSTOM action にて作成したExtension Providerを指定 ◼ AuthorizationPolicyにて 対象トラフィックを指定可 ◼ IstioOperatorは既存の リソースとは別にデプロイ可 ◼ IstioOperatorの導入もしく は、meshConfig直接操作 が必要 ◼ Control Planeの再起動要 EnvoyFilter 操作 EnvoyFilterリソースにてプロキシの ext_authz機能を制御 ◼ meshConfig操作不要 ◼ EnvoyFilterのみで処理が 完結 ◼ Envoy Proxyの知識要 ◼ AuthorizationPolicyの分 解能でトラフィック制御する 場合、設定が複雑化

© Hitachi, Ltd. 2022. All rights reserved. 外部認可の設定例 - Extension Provider Extension Providerによる外部認可設定 ▪ httpbin サービスにOpen Policy Agent の外部認可を適用する例 ▪ IstioOperatorはprofileをemptyにすると、既存の環境に影響を与えず設定を追記できる 39 ## Extension Providerの定義 apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata: name: opa spec: profile: empty # Istio本体のインストールは行わない meshConfig: extensionProviders: - name: opa envoyExtAuthzGrpc: service: opa.istio-system.svc.cluster.local port: 9191 timeout: 0.5s failOpen: false # エラー時は Deny とする statusOnError: 503 # エラー時のステータスコード ## Extension Providerの反映 apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: opa spec: selector: matchLabels: app: httpbin action: CUSTOM provider: name: opa rules: - {}

© Hitachi, Ltd. 2022. All rights reserved. 外部認可の設定例 EnvoyFilterによる例 ▪ Extension Providerと 設定内容は同一 ▪ ext_authzにOPAを 割り当てる ▪ Istioプロキシ(Envoy)の 操作になるため慣れが必要 ▪ 書籍 Istio in Action の14章が分かりやすい apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: opa spec: workloadSelector: labels: app: httpbin configPatches: - applyTo: HTTP_FILTER # http connection manager内に適用される match: context: ANY # [SIDECAR_INBOUND|SIDECAR_OUTBOUND|GATEWAY] から選択 patch: operation: INSERT_BEFORE value: name: envoy.ext_authz typed_config: "@type": type.googleapis.com/envoy.extensions.filters. http.ext_authz.v3.ExtAuthz grpc_service: envoy_grpc: cluster_name: outbound|9191||opa.istio-system.svc.cluster.local timeout: 0.5s transport_api_version: V3 status_on_error: code: ServiceUnavailable # エラー時のステータスコード failure_mode_allow: false # エラー時はDenyとする 40

© Hitachi, Ltd. 2022. All rights reserved. 外部認可の例 下記の例を紹介 ▪ Open Policy Agent (OPA) 連携 ▪ Keycloak/OAuth2 Proxy連携 41

© Hitachi, Ltd. 2022. All rights reserved. Open Policy Agent(OPA)連携 ▪ OPA : OSSのポリシーエンジン。入力値をポリシーで判定し true/false を返す ▪ opa-envoy-plugin ◇ Istioプロキシの外部認可機能と連携するための拡張機能。gRPCで通信 ◇ openpolicyagent/opa:-envoy コンテナを用いる ▪ OPAスタンドアロン、もしくはIstioプロキシのサイドカーとしてデプロイ 42 Proxy Svc2 Open Policy Agent トラフィック User 外部認可 ALLOW or DENY Svc1 Service アイコン引用元: https://cncf-branding.netlify.app/projects/opa/

© Hitachi, Ltd. 2022. All rights reserved. opa-envoy-pluginのデプロイ ▪ OPAをスタンドアロンでデプロイ ▪ 引数やファイルで設定を付与 ◇ https://www.openpolicyagent.org/ docs/latest/envoy-introduction/ ▪ IstioプロキシからOPAの呼び出し方法 は前述の外部認可を参照 kind: Deployment apiVersion: apps/v1 metadata: name: opa spec: ... spec: containers: - name: opa image: openpolicyagent/opa:0.42.2-envoy args: - "run" - "--server" - "--addr=localhost:8181" - "--diagnostic-addr=0.0.0.0:8282" - "--set=plugins.envoy_ext_authz_grpc.addr=:9191" - "--set=plugins.envoy_ext_authz_grpc.path =envoy/authz/allow" - "--set=decision_logs.console=true" - "--set=status.console=true" - "/opt/policy.rego" livenessProbe: httpGet: path: /health?plugins scheme: HTTP port: 8282 volumes: - name: policy configMap: name: policy 43

© Hitachi, Ltd. 2022. All rights reserved. opa-envoy-pluginの入出力値 入力値 ▪ トラフィックとしての情報はほぼ揃う ◇ 送信元・宛先IP・Port、Host、Path、HTTP Methods、HTTP Headers、Body(一部) ▪ フォーマット https://www.openpolicyagent.org/docs/latest/envoy-primer/#example-input 出力値 ▪ アクセス可否の結果以外にも様々な値を制御可能 ▪ アクセス可否により反映できる内容が異なる ◇ アクセス拒否時: 送信元に返す headers, http_status, body を制御 ◇ アクセス許可時: request_headers_to_remove, headers にて宛先に渡す Headersを制御し、 response_headers_to_add にて送信元のHeadersも制御 44

© Hitachi, Ltd. 2022. All rights reserved. 認可ポリシーのサンプル GETメソッド以外の操作を拒否し、 ステータスコード405を返すポリシー (右例) ▪ 標準だと403が返るが変更 ▪ 返り値はallowオブジェクトに含める ◇ status_codeなどを変数として 返す方法では動作せず apiVersion: v1 kind: ConfigMap metadata: name: opa-policy namespace: istio-system labels: app: istio-authgateway istio: authgateway data: policy.rego: | package envoy.authz import future.keywords # allow if { }等に必要 import input.attributes.request.http # 変数短縮 default allowed := false # GETならallowedをtrueにする allowed if { http.method == "GET" } # allowedに基づきステータス変更 status_code := 200 { allowed } else := 405 # envoy_ext_authz_grpc.pathである allow オブジェクトに # 必要情報を追加 allow["allowed"] := allowed allow["http_status"] := status_code 45 Deleteメソッドのときに405が変える

© Hitachi, Ltd. 2022. All rights reserved. KeycloakとOAuth2 Proxyを用いたユーザ認証(1/2) ▪ KeycloakなどのIDプロバイダと連携すると、Web GUIを用いたユーザ認証が可能 ◇ Istio版の認証プロキシに相当。サービス側での認証機能が不要となる ◇ IstioとKeycloakの仲介としてOAuth2 Proxyを利用 ◇ Kubeflowも本方式での認証認可を実現している（ツールスタックは異なる） 46 Proxy Svc2 トラフィック User 外部認可 OAuth2 Proxy Keycloak Open ID Connect リダイレクト アイコン引用元: https://design.jboss.org/keycloak/index.htm、 https://github.com/oauth2-proxy/oauth2-proxy Keycloakログイン画面

© Hitachi, Ltd. 2022. All rights reserved. KeycloakとOAuth2 Proxyを用いたユーザ認証(2/2) 動作原理 1. Istioの外部認可にて認証プロキシであるOAuth2 Proxyを呼び出す 2. OAuth2 ProxyがOpenID Connectプロトコルに従いJWTを取得 3. IstioのRequestAuthenticationにてJWTを検証 OAuth2 ProxyにIstioを被せる意義 ▪ Ingress連携 ▪ サービスの構成の均一化 今後について ▪ Helm Chart化 → 有用そうなら一般公開を検討 ▪ OAuth2 Proxyの代わりにOPAが使えないか(!?) 47 Proxy Svc2 User 1. 外部認可 OAuth2 Proxy Keycloak 2. Open ID Connect アイコン引用元: https://design.jboss.org/keycloak/index.htm、 https://github.com/oauth2-proxy/oauth2-proxy

© Hitachi, Ltd. 2022. All rights reserved. OPAを用いたKeycloak連携の検討 OAuth2 Proxyの代わりにOPAを使う意義 ▪ ユーザ認証と認可制御の統合 ▪ SAMLなどOAuth2 Proxyサポート外のプロトコルの適用 問題1 Keycloakへのリダイレクト ▪ OPAは外部認可の際、ステータスコードやHTTPヘッダを操作できる ▪ ステータスコードを302(Redirect)にし、locationヘッダを設定して 認可をDeniedとすればリダイレクトにならないか → リダイレクトすることを確認 問題2 セッション管理 ▪ OPAでセッション管理するとロジックが複雑化 ▪ 暗号化したセッション情報をユーザのCookieに持たせる方針 → 実験レベルではあるが、動作の見込み 48

© Hitachi, Ltd. 2022. All rights reserved. その他、Istioセキュリティプラクティス Istio は distroless image に対応 ▪ distroless image: 実行ファイルやライブラリを極力排除した軽量コンテナイメージ ▪ プログラム（=攻撃対象になりうる要素）が少なくセキュア ▪ istioctl install --set tag=1.14.2-distroless などとして利用 Istio Security Analyzer ▪ サードパーティ性のIstioのセキュリティ診断ツール ▪ Istio公式ドキュメントのSecurity Best Practiceを反映 ▪ Control Planeのバージョン、脆弱性、設定の問題を通知 ▪ CLI以外にコンテナイメージ(vpnhub1/istio-security-analyzer)がある 49

© Hitachi, Ltd. 2022. All rights reserved. Istio Security Analyzer コマンドを実行すると、contextが紐づいているKubernetesを診断 50 $ ./scanner analyzer mesh 2022-07-26T21:27:12.474336Z info Starting Kubernetes cluster for Istio Security scanning. 2022-07-26T21:27:12.474628Z info Ensure the config store has synced. 2022-07-26T21:27:12.475121Z info Kubernetes config store not synced yet, waiting. 2022-07-26T21:27:15.475862Z info Staring the scanning. 2022-07-26T21:27:16.113990Z info Report ========================================== Istio Security Report Control Plane Version - 1.14.1 Distroless Warning ❗ pod istio-authgateway-56c747f6f9-9fwl8 can use a distroless image for better security, current docker.io/istio/proxyv2:1.11.8 CVE Report Config Report We scanned 2 security configurations, and 10 networking configurations. ❌ networking.istio.io/v1alpha3/Gateway sock-shop/sock-shop-gateway: host "*" is overly broad, consider to assign aspecific domain name such as foo.example.com ==========================================

© Hitachi, Ltd. 2022. All rights reserved. その他Istioセキュリティプラクティス 認証認可状況の確認 ▪ Kiali や istioctl を使うと効率的 ▪ Kiali : Workloads画面にて、Podごと に適用されているポリシーを確認できる ▪ istioctl : authz check機能により、 指定したPodのセキュリティ設定を確認 できる ▪ 特にKialiはNamespace全体など、 範囲で適用されているポリシーも 紐づけて表示するため強力 51 $ istioctl x authz check deployment/user-db -n sock-shop ACTION AuthorizationPolicy RULES ALLOW user-db-allow-only-user-service.sock-shop 2 LOG user-db-audit.sock-shop 1 関連ポリシー (PA: PeerAuthentication) Kiali istioctl

© Hitachi, Ltd. 2022. All rights reserved. まとめ ▪ マイクロサービスのセキュリティ戦略 ◇ アクセス制御、回復性、セキュリティ監視、権限の最小化 ◇ Secure by Default や Principle of Least Privilege ▪ Istioのセキュリティ機能 ◇ サービス認証、ユーザ認証 ◇ トラフィック情報に基づく認可制御 ◇ 外部認可機能を用いたOPAやKeycloakとの連携 52

© Hitachi, Ltd. 2022. All rights reserved. 参考文献 1. Chandramouli, Ramaswamy. "Microservices-based application systems." NIST Special Publication 800.204 (2019) 2. Chandramouli, Ramaswamy, and Zack Butcher. "Building secure microservices-based applications using service-mesh architecture." NIST Special Publication 800.204A (2020) 3. Chandramouli, Ramaswamy, Zack Butcher, and Aradhna Chetal. "Attribute-based Access Control for Microservices-based Applications Using a Service Mesh." NIST Special Publication 800.204B (2021) 4. Chandramouli, Ramaswamy. "Implementation of DevSecOps for a Microservices-based Application with Service Mesh." NIST Special Publication 800.204C (2022) 5. "NGAC Vs RBAC Vs ABAC" Tetrate https://www.tetrate.io/blog/rbac-vs-abac-vs-ngac/ (accessed July 23, 2022) 6. "Service meshes are on the rise — but greater understanding and experience are required", Cloud Native Computing Foundation (2022) 7. "Istio" https://istio.io/ (accessed July 23, 2022) 8. "Envoy documentation — envoy 1.24.0-dev-6c7513 documentation" https://www.envoyproxy.io/docs/envoy/latest/ (accessed July 23, 2022) 9. Christian E. Posta and Rinor Maloku, "Istio in Action" Manning Publications (2022) 10. Jianfei Hu, "Automate Istio Best security practice", IstioCon 2022 (2022) 11. Yannis Zarkadas, "Kubeflow: Authentication with Istio + Dex" Arrikto https://www.arrikto.com/blog/kubeflow/news/kubeflow-authentication-with-istio-dex/ (accessed July 23, 2022) 12. Luke Addison. "Istio OIDC Authentication" Jetstack Blog https://www.jetstack.io/blog/istio-oidc/ (2021) 53

© Hitachi, Ltd. 2022. All rights reserved. 商標 ▪ Istioは、Open Usage Commonsの米国にまたはそ の他の国における登録商標または商標です ▪ Envoyは、The Linux Foundationの米国またはその 他の国における登録商標または商標です ▪ Vaultは、HashiCorpの米国にまたはその他の国にお ける登録商標または商標です ▪ Open Policy Agentは、The Linux Foundationの 米国またはその他の国における登録商標または商標 です ▪ Keycloakは、 Red Hat, Inc.の米国またはその他の 国における登録商標または商標です ▪ OAuth2 Proxyは、OAuth2 Proxyの米国またはそ の他の国における登録商標または商標です ▪ Kubeflowは、 Google LLCの米国またはその他の国 における登録商標または商標です ▪ Istio Security Analyzerは、Tetrate.io Inc. の米国 またはその他の国における登録商標または商標です ▪ Kialiは、 Red Hat, Inc.の米国またはその他の国にお ける登録商標または商標です ▪ NISTは、National Institute of Standards and Technology U.S. Department of Commerceの 米国またはその他の国における登録商標または商標 です ▪ その他記載の会社名、製品名、サービス名、その他固 有名詞は、それぞれの会社の商標または登録商標で す ▪ 本発表中の文章、図では、TM、🄬マークは表記して おりません。 54

No content