CNSC 2022、日立のエンジニアがNISTの仕様をベースにIstioのセキュアな設定を解説

CloudNative Security Conference 2022から、サービスメッシュ（Istio）におけるセキュリティの詳細な設定を解説するセッションを紹介する。セッションを担当したのは株式会社日立製作所の研究開発グループの井出貴也氏だ。タイトルは「Istioを活用したセキュアなマイクロサービスの実現：アプリ透過型のユーザ及びサービス認証認可」で、前半でマイクロサービスのセキュリティについてNIST（National Institute of Standards and Technology、米国標準技術研究所）のガイドSP800-204について概要と特徴を紹介した後に、サービスメッシュのオープンソースソフトウェアであるIstioについて紹介、Istioの機能のうち、セキュリティに関連する部分、認証と認可について掘り下げるという内容となっている。

井出氏のセッション。所属は研究開発グループだ

マイクロサービスの良さは認めつつもセキュリティの観点からは複雑であり、何からの指針が必要であると述べ、その具体例としてNISTのガイドラインSP800-204を紹介している。

サービスメッシュのセキュリティにおける指針が必要

NISTが作成したガイドラインを紹介

NISTのSP800-204には4つのセクションがあり、今回はそのうちの204、204A、204Bについて触れると説明。マイクロサービスを実装する際の仕組みであるCI/CDパイプラインなどについては触れないと語った。

NIST SP800-204におけるセクションの概要

NISTの仕様については以下のリンクを参照されたい。

NISTの仕様：Security Strategies for Microservices-based Application Systems

マイクロサービスの実装パターンのひとつであるサービスメッシュについて簡単に説明し、アプリケーションを構成する機能をサービスとして分割、そのサービスの通信を担当する部分にProxyという別のプロセスを同居させるいわゆるサイドカー実装をベースに解説している。

Proxyがサービス間通信を担当し、管理はコントロールプレーンとして別プロセスが受け持つ形

サービスメッシュの利用者視点でのセキュリティは4つに分類されるとして、通信の保護と認証認可、耐障害性と回復力の向上、セキュリティ監視、権限の最小化に分けて井出氏が注目するポイントについて解説を行った。

SP800-204に関する井出氏の総括

ガイドライン全体について、規定値としてセキュアな設定が必要としている点、サービスやユーザーに対する権限を最小限にする点をまとめたのがこのスライドになる。

その上でサービスメッシュのIstioを例に、主としてサービス間通信におけるセキュリティ設定の詳細を解説する後半に移った。

Istioの紹介。Google、Red Hat、IBMが開発をリード

ここからIstioの認証、認可の機能について詳細に解説が始まった。

Istioの認証、認可に関して詳細な解説を行った

サービス間認証やID、外部の認証局を使った場合のコマンド、ユーザー認証、認可についてIstioの設定内容についても触れながら解説を行った。

外部の認証局を使った場合のコマンドなどを紹介

外部認可について、このスライドではOpen Policy Agent（OPA）を使ったケースで紹介。外部の判定については都度、通信が発生するためにレイテンシーが増える可能性があることをコメントしている。

Istioにおける外部認可については2種類の方法があるとして、Extension Provider、Envoy Filterについて説明を行った。

外部認可の設定、2種類を説明

認可についてはOPA連携、ユーザー認証についてはKeycloak/OAuth2 Proxy連携の解説を行った。

アクセス認可についてOPAを使った例の解説

ユーザー認証についてはKeycloakとOAuth2 Proxyの連携を紹介

ここでは唐突にKeycloakが登場しているが、Keycloakは日立のエンジニアがメンテナーとしてプロジェクトの統括を行っているIdentity and Access Managementのためのオープンソースソフトウェアだ。

参考：OSS「Keycloak」開発プロジェクトのメンテナに日立の社員が就任

ここではサービスからユーザー認証を行う場合にProxy → OAuth2 Proxy → Keycloakという順番で連携している部分を解説している。IstioとKeycloakの間にOAuth2 Proxyが仲介役として使われている。

このシステム構成でOAuth2 ProxyをOPAに置き換えることができないか？ ということを説明しているのが、次のスライドだ。

OAuth2 Proxyの替わりにOPAを使うことは可能か

ここではユーザー認証と認可を同じモジュール（OPA）で行うという試みについて解説している。Keycloakへのリダイレクト処理の実装可能性とセッション管理についても触れ、実験レベルでは実装可能であると説明している。

まとめとしてNISTのガイドラインの要点の紹介、そしてユーザー認証、認可におけるIstioの詳細な設定例、最後にOPA、Keycloakなどとの連携の例を挙げている。

井出氏のセッションのまとめ

前半のNISTのガイドライン紹介が後半のIstioの実装例と対比されておらず、Istioの設定における要点の詳細な説明や注意点という構成になっているためにIstioを深く知らないと参考にしづらい点が少々気になった。

またKeycloakやOPA、OAuth2 Proxyなどが唐突に登場しているが、それらのソフトウェアを知っていることが前提の中級者向けと言えばその通りだが、前半が俯瞰的に総括しているのに後半は顕微鏡で観察しているような印象を受けてしまった。研究者的な視点といえばその通りかもしれないが、別の機会により全体的な内容を期待したい。

セッションの動画は以下のリンクから参照して欲しい。

動画：Istioを活用したセキュアなマイクロサービスの実現: アプリ透過型のユーザ及びサービス間の認証認可