Keycloakと認可プロダクトを利用したマイクロサービスにおける認証認可の実現

第2回ではコンテナ環境にKeycloakをデプロイし、シングルサインオンを実現する方法を紹介しました。第3回ではKeycloakに加えて、認可を実現できるプロダクトを用いたマイクロサービスにおける認証認可のアーキテクチャについて紹介します。認可を実現できるプロダクトとして、CNCFのGraduatedプロジェクトであるOPA（Open Policy Agent）と、CNCFプロジェクトではありませんが認可フレームワークであるCasbinを利用します。

1. マイクロサービスにおける認証認可の課題

システムのアーキテクチャはモノリシックなシステムからサービス指向アーキテクチャ、そしてクラウドが普及するとともにマイクロサービスアーキテクチャへと変化してきました。クラウド上のすべてのシステムでマイクロサービスアーキテクチャが採用されるわけではありませんが、急速なビジネス環境の変化へ追従するアジリティが必要なシステムでは、サービスを分割し疎結合化したマイクロサービスアーキテクチャが採用されます。

図1はモノリシックアーキテクチャとサービス指向アーキテクチャ、マイクロサービスアーキテクチャの概要図です。モノリシックアーキテクチャはシステムが単一のサービスから構成され、そのサービスを構成するコンポーネントは互いに密結合となっています。モノリシックアーキテクチャではすべてのコンポーネントが連携して1つのサービスとして機能します。それに対してサービス指向アーキテクチャではシステムが複数のサービスから構成され、これらはエンタープライズサービスバスを経由して通信を行います。さらにマイクロサービスアーキテクチャではシステムが複数のサービスから構成され、それらは互いに疎結合で独立しています。また、サービス指向アーキテクチャとは異なりサービス同士が直接通信を行います。

図1：モノリシックアーキテクチャ、サービス指向アーキテクチャ、マイクロサービスアーキテクチャの概要

図1からわかるようにマイクロサービスアーキテクチャは多数のサービスが直接通信を行うようなアーキテクチャとなっています。このような場合、どのサービスが認証や認可を行うのか、ネットワーク上のどの位置で認証や認可のポリシーを適用するのかについて検討しなければなりません。モノリシックアーキテクチャやサービス指向アーキテクチャの場合、システムがリクエストを受けつける一点で認証も認可も実施できましたが、マイクロサービスではそれほど単純ではありません。サービスが分割されているため、多数の関係チームと調整が必要になりますし、認証認可機能が密結合のポイントとなりアジリティの低下や性能面でシステムのボトルネックにもなりえます。以降ではマイクロサービスにおける認証認可アーキテクチャの基本的な考え方と、Keycloak、OPA、Casbinを用いたマイクロサービスにおける認証認可アーキテクチャの実現方法を紹介します。

2. マイクロサービスにおける認証認可の基本的な考え方

マイクロサービスの認証認可を考えるうえで基本となる考え方や考慮ポイントを整理した資料をNIST（アメリカ国立標準技術研究所）が公開しています。マイクロサービスの認証認可について議論する際は、これらの資料をベースとして議論されることが多いです。以下にマイクロサービスアーキテクチャにおける認証認可に関連する資料を列挙します。

NIST SP 800-204 Security Strategies for Microservices-based Application Systems

マイクロサービスとは何かという点や、マイクロサービスの特徴について記載している。また、マイクロサービスの認証認可を考えるうえで重要となるAPIの分類方法（パブリックAPI、プライベートAPI、パートナAPI）を示している。さらにマイクロサービスアーキテクチャをAPI Gatewayパターン（単一API Gateway、分散API Gateway）とサイドカープロキシを利用したサービスメッシュパターンに分類しそれぞれの特徴を説明している。

NIST SP 800-204A Building Secure Microservices-based Applications Using Service-Mesh Architecture

マイクロサービスの認証認可ポリシーにおける推奨事項が記載されている。とくにネットワーク通信における推奨事項についての記載が多く、例えばサービス間の通信ではmTLS（mutual TLS）を利用することや外部への通信をデフォルトで拒否することなどがあげられる。

NIST SP 800-204B Attribute-based Access Control for Microservices-based Applications Using a Service Mesh

マイクロサービスのセキュリティ要件について言及したうえで、マイクロサービスにおける認証認可のあるべき姿を示している。属性ベースアクセス制御のモデルアーキテクチャが示されており、認証認可のアーキテクチャを整理する際の参考となる。

NIST SP 800-207 Zero Trust Architecture

ゼロトラストとは何か、ゼロトラストの考え方はどういったものかについて記載。ゼロトラストとしてあるべき状態を示す一方で、実際のシステムでは理想的なゼロトラストの実現が難しい点も言及されている。そのうえでマイクロサービスのセキュリティの考え方や、ゼロトラストを実現する上での妥協点、認証認可ポリシーの適用範囲についての指針が示されている。

本記事でも、これらNISTの資料をベースとしてマイクロサービスの認証認可について考えます。

マイクロサービスの認証認可、とりわけユーザーの認証認可に関しては属性ベースアクセス制御の考え方に基づいて実施することが一般的となっています。例えばKeycloakでユーザーの認証を行った際にはJWT（JSON Web Token）形式のトークンが発行されます。このトークンにはユーザーに関する情報が含まれているため、それらの情報を用いて認可を行うことが可能です。これが属性ベースアクセス制御の代表的な例です。NIST SP 800-204Bでは属性ベースアクセス制御のアーキテクチャについて説明されています。NISTの資料を参考として、図2に属性ベースアクセス制御の簡易的なアーキテクチャを示します。このアーキテクチャは強制・決定・データ・統制の4つのレイヤーからなり、それらを7つのポイントが構成しています。マイクロサービスにおける認証認可を検討する際は、これら7つのポイントの中でもとりわけPEP（ポリシー強制ポイント）とPDP（ポリシー決定ポイント）を意識することが重要です。

図2：属性ベースアクセス制御のアーキテクチャ

それぞれのポイントに関する説明は以下の通りです。

3. マイクロサービスアーキテクチャの分類

マイクロサービスアーキテクチャの分類はNIST SP 800-204で説明されています。ここでは、マイクロサービスアーキテクチャにおいて認証認可を実現するため、NIST SP 800-204を参考にあらためてパターンを整理します。図3に示したように、マイクロサービスアーキテクチャはAPI Gatewayパターンとサービスメッシュパターンの2種に大別されます。

API Gatewayパターンでは複数のマイクロサービスでAPI Gatewayを共有する方式で、API Gatewayはマイクロサービスの外側に配置されます。一方、サービスメッシュパターンでは各マイクロサービスに専用のプロキシを配置します。このプロキシはKubernetes環境においてマイクロサービスと同じPod内に配備されるため、サイドカープロキシと呼ばれます。そのためサービスメッシュパターンはサイドカーパターンとも呼ばれます。なお、API Gatewayパターンは単一のAPI Gatewayを利用するパターンとクライアントのチャネルに応じて複数のAPI Gatewayを配置する分散API Gatewayパターンに分けられます。

図3：API Gatewayパターンとサービスメッシュパターン

また図4に示すように、単一API Gatewayパターンや分散API Gatewayパターン、サービスメッシュパターンは組み合わせて適用されることもあります。

図4：API Gatewayパターンおよびサービスメッシュパターンの組み合わせ例

4. マイクロサービスアーキテクチャにおける認証認可

ここまでマイクロサービスにおける認証認可を議論するうえで重要となるPEPやPDPなどの考え方、API Gatewayパターンやサービスメッシュパターンによるマイクロサービスの分類方法をNISTの資料をベースに紹介しました。次にこれら2つの考え方を統合し、あらためてマイクロサービスにおける認証認可のアーキテクチャについて考えます。

PDPやPEPはAPI Gatewayとサービスメッシュのパターン上にマッピングできます。マッピングのパターンは無数にあるため、ここでは一例を示し、それらのパターンのメリットとデメリットを説明します。なお、PDPとPEP以外のポイントは検討対象外とします。また、マイクロサービスごとにきめ細かく認証認可のポリシーを適用する際は、マイクロサービス自身がPDPやPEPになることもあります。

図5は単一API Gatewayをベースとして、分散API Gatewayおよびサービスメッシュを組み合わせたパターンにPDPとPEPをマッピングしています。PDPとしてはアクセス可否の判断を行えるようなアプリケーションが用意されているイメージとなります。図5の例ではPEPがクライアントに近いGatewayに配置されています。このパターンではPEPにおいてシステム全体に対して共通で利用されるポリシーが適用されます。特定のマイクロサービスに適用されるようなポリシーは、図に示したPEPより各マイクロサービスに近い位置で適用することが推奨されます。図5のようにPEPを配置した場合、ポリシーの変更が発生した際に修正箇所が少なく済む一方で、ポリシーの変更によって影響を受けるサービスの数が多くなる点に注意しなければなりません。影響範囲の拡大はアジリティの低下を招くからです。

図5：クライアントに近い位置にPEPを配置するパターン

図6のマッピングでは、図5よりマイクロサービスに近い位置にPEPを配置しています。したがって、システム全体として共通で適用されるポリシーだけでなく、特定のサービス群に対して適用されるポリシーをPEPで適用しても差し支えありません。このパターンではサイドカープロキシがPEPとなっているケースを除き、API Gatewayが複数のサービスにまたがって利用されています。そのため個別のマイクロサービスに対して適用されるようなポリシーは、API Gatewayで適用されるべきではありません。マイクロサービスに近い位置にPEPを配置すると、ポリシーを管理するポイントが増えたり、ポリシーの変更が発生した際の修正箇所が増えたりする可能性はありますが、修正による影響範囲を限定できるというメリットがあります。

図6：マイクロサービスに近い位置にPEPを配置するパターン

図7に示すように、PDPやPEPは多段的に設けられることもあります。システムの規模や将来における変更の可能性、頻度、また認証認可ロジックの複雑さを鑑みて適切なパターンを検討することが必要となります。

図7：多段的にPEPを配置するパターン

5. マイクロサービス認証認可の例（OPA）

OPA（Open Policy Agent）は汎用的なポリシーエンジンであり、CNCFのGraduatedプロジェクトです。OPAを用いることでマイクロサービスにおけるユーザーの認可を実現できます。図8にOPAを用いた認証認可アーキテクチャの例を示します。単一API Gatewayパターンや分散API Gatewayパターンでも認証認可を実現できますが、図9ではサービスメッシュパターンを想定しており、Envoyがサイドカープロキシとなっています。このアーキテクチャではEnvoyがPEP（ポリシー強制ポイント）、OPAがPDP（ポリシー決定ポイント）に相当します。なお、EnvoyはCNCFのGraduatedプロジェクトであり、Istio（CNCF Graduatedプロジェクト）やConsulなどのサービスメッシュプロダクトに組み込まれています。したがって、図8のアーキテクチャはそれらのサービスメッシュプロダクトを利用することで実現できます。

図8：KeycloakとOPAを利用した認証認可の実現例

図8における認証認可の流れを簡単に説明します。

1. Keycloakなどの認可サーバと認証クライアントおよびユーザー間で認証連携を行います。ここではOpenID Connectの認可コードフローを用いて認証連携を行うことを想定しています。認証連携により、認証クライアントはマイクロサービスのAPIを呼び出すための「アクセストークン」を認可サーバから取得・管理します
2. 認証クライアントはリクエストにアクセストークンを付けてマイクロサービスのAPIを呼び出します。この際、APIリクエストはサイドカープロキシであるEnvoyを経由します
3. EnvoyはAPIリクエストを受け取ると、アクセストークンを含むそのリクエストに関する情報をOPAに連携します。アクセス可否の判断はPDPであるOPAが実施し、Envoyはその判断結果に基づいてリクエストの通過・遮断を実施します。OPAを用いた認可は、Envoyの「External Authorization Filter」機能を利用することで実現できます
4. アクセスが許可された場合、EnvoyはマイクロサービスのAPIを呼び出します

上記のような流れで、マイクロサービスアーキテクチャにおけるユーザーの認証認可を実現できます。なお、Envoyなどのサイドカープロキシではなく、マイクロサービス自身がOPAと連携して認可を実施するような方式もあります。マイクロサービスごとにきめ細かい認可を行いたいケースではこのような方式がとられます。

6. マイクロサービス認証認可の例（Casbin）

オープンソースの認可フレームワークであるCasbinとKeycloakを用いてマイクロサービスにおける認証認可を実現する方法を紹介します。KeycloakとCasbinを用いると、図9のような認証認可アーキテクチャが実現できます。この例では、マイクロサービスの前段にAPI Gatewayを配置する方式（ここでは説明を簡略化するため単一API Gatewayパターン）としています。認可サーバとしてKeycloakを利用し、アクセス可否の判断を下す認可サービスとしてCasbinを利用しています。このアーキテクチャではAPI GatewayがPEP（ポリシー強制ポイント）、認可サービスがPDP（ポリシー決定ポイント）に相当します。なお、Casbinは認可フレームワークであり、GoやRust、C++、Javaなどさまざまな言語のSDKが公開されています。実際のシステムを構築する際はこれらのSDKを利用して認可サービスを実装します。その際のAPI GatewayとしてはEnvoyなどが利用できます。

図9：KeycloakとCasbinを利用した認証認可の実現例

図9のアーキテクチャにおける認証認可の流れはOPAの例とおおむね同じです。CasbinではOPAほど複雑な認可はできませんが、学習コストが低くSDKも簡単に利用できるため、認可サービスに気軽に組み込むことが可能です。OPAなどの既存プロダクトを利用するのか、Casbinなどのフレームワークを利用して自前で認可サービスを実装するのかは、実現したい認可の内容、開発コストやスケジュールを考慮して決めるとよいでしょう。

第3回では、マイクロサービスにおける認証認可の考え方を説明しました。また、CNCFのGraduatedプロジェクトであるOPAや、認可フレームワークであるCasbinを用いてマイクロサービスアーキテクチャにおいて認証認可を実現する方法を紹介しました。