Istioを活用したセキュアなマイクロサービスの実現/Secure Microservices with Istio

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

View Slide

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

View Slide

マイクロサービスのセキュリティ戦略
2

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

▪ 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パイプラインにてシステムに
セキュリティを付与するための設計

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

サービスメッシュ利用者の視点では、ネットワーク層のセキュリティ戦略は大きく4種に分類
12
Svc4
Svc3
Svc2
Svc1
UI
Microservices
Ingress/
Egress

View Slide

13
Svc4
Svc3
Svc2
Svc1
UI
Microservices
Ingress/
Egress
サービス間認証
ユーザ認証
アクセス(認可)制御
通信暗号化
Ingress/Egress
通信管理
通信の保護と
認証・認可

View Slide

ロード・バランシング
流量制御
リトライ制御
タイムアウト
サーキットブレーカー
耐障害性と
回復力の向上
Client
14
Svc4
Svc3
Svc2
Svc1
UI
Microservices
Ingress/
Egress
ユーザ認証
通信暗号化
Ingress/Egress
通信管理
通信の保護と
認証・認可

View Slide

トレース収集
ログ収集
メトリクス収集
セキュリティ
監視
Monitoring
流量制御
リトライ制御
タイムアウト
耐障害性と
回復力の向上
Client
15
Svc4
Svc3
Svc2
Svc1
UI
Microservices
Ingress/
Egress
ユーザ認証
通信暗号化
Ingress/Egress
通信管理
通信の保護と
認証・認可

View Slide

トレース収集
ログ収集
メトリクス収集
セキュリティ
監視
Monitoring
流量制御
リトライ制御
タイムアウト
耐障害性と
回復力の向上
Client
権限の
最小化
コンテナ特権排除
サービスメッシュ操作
権限の限定化
16
Svc4
Svc3
Svc2
Svc1
UI
Microservices
Ingress/
Egress
ユーザ認証
通信暗号化
Ingress/Egress
通信管理
通信の保護と
認証・認可

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

セキュリティ戦略一覧（再掲）
24
カテゴリ目的セキュリティ戦略概要
通信の保護と
認証・認可不正アクセス防止
回復力と
耐障害性
攻撃時の
可用性担保
リトライ・タイムアウトエラー時のリトライ制御とハングアップ時のタイムアウトでロバストにする
メトリクス収集トラフィック量、エラー率、レイテンシをベースライン監視する

View Slide

セキュリティ戦略一覧（再掲）
25
カテゴリ目的セキュリティ戦略概要
通信の保護と
認証・認可不正アクセス防止
回復力と
耐障害性
攻撃時の
可用性担保
リトライ・タイムアウトエラー時のリトライ制御とハングアップ時のタイムアウトでロバストにする
メトリクス収集トラフィック量、エラー率、レイテンシをベースライン監視する
以降のスコープ

View Slide

Istioの認証認可機能
26

View Slide

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

View Slide

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

View Slide

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

View Slide

▪ 非常に強力、かつ通常時は意識しなくて良い
▪ 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 ラベルが付いたプロキシのみ平文を許容
metadata:
name: "access-to-legacy"
namespace: default
spec:
selector:
matchLabels:
accessTo: legacy
mtls:
mode: PERMISSIVE
mTLSを用い、送信・受信側双方のPodが互いを
認証を行う機能。デフォルトで有効化されている
30

View Slide

サービス間認証の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

View Slide

サービス間認証における外部認証局の利用
▪ 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
外部認証局の利用

View Slide

ユーザ認証
▪ RequestAuthenticationリソースにて設定
▪ ただし、JWT取得自体はスコープ外
◇ JWTの取得はサービス側で行うか
後述の外部認可機能を使う
▪ RequestAuthenticationを設定していても
JWTを含まないリクエストには適用されない
→別途AuthrizationPolicyにて
JWTの値を含むか確認要(右例下)
## foo.com にて JWT を検証する
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が存在する通信のみ通過
kind: AuthorizationPolicy
metadata:
name: httpbin
spec:
selector:
matchLabels:
app: httpbin
rules:
- from:
- source:
requestPrincipals: ["*"] # jwt内のIDが存在する 33
リクエスト内トークン(JWT)の正当性を
外部Issuerに問い合わせて検証する

View Slide

## User Serviceまたは監視系からのアクセスのみ許可する
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
トラフィック情報に基づく
属性ベースアクセスコントロール

View Slide

認可(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または監視系からのアクセスのみ許可する
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

View Slide

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

View Slide

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

View Slide

外部認可の設定
▪ 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の分
解能でトラフィック制御する
場合、設定が複雑化

View Slide

外部認可の設定例 - 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の反映
metadata:
name: opa
spec:
selector:
matchLabels:
app: httpbin
action: CUSTOM
provider:
name: opa
rules:
- {}

View Slide

外部認可の設定例
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

View Slide

外部認可の例
下記の例を紹介
▪ Open Policy Agent (OPA) 連携
▪ Keycloak/OAuth2 Proxy連携
41

View Slide

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/

View Slide

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

View Slide

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

View Slide

認可ポリシーのサンプル
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が変える

View Slide

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ログイン画面

View Slide

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

View Slide

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

View Slide

その他、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

View Slide

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
==========================================

View Slide

その他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

View Slide

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

View Slide

参考文献
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

View Slide

商標
▪ 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

View Slide

View Slide

Istioを活用したセキュアなマイクロサービスの実現/Secure Microservices with Istio

Istioを活用したセキュアなマイクロサービスの実現/Secure Microservices with Istio

id

More Decks by id

Other Decks in Technology

Featured

Transcript