CNCFプロジェクトとKeycloakの動向
Keycloakとは、ID管理・アクセス管理(IAM:Identity and Access Management)のOSSであり、WebアプリケーションおよびAPI・マイクロサービスの認証や認可をKeycloakに任せることができます。前回の連載ではKeycloakのAPI認可のユースケースを紹介しました。それ以降のKeycloakに関するトピックとして、2023年4月にKeycloakはCloud Native Computing Foundation(以下、CNCF)のIncubatingプロジェクトとして承認されたことが挙げられます。これにより、IAM分野のOSSとして定番になっていくことが期待されます。また、その過程でKeycloakやコミュニティにも大きな変更点がありました。
本連載では、CNCFプロジェクトになったKeycloakについて、その背景や変更点、また典型的なユースケースであるシングルサインオンやAPI・マイクロサービスの認可について、CNCFのOSSと組み合わせた実現例を紹介します。
第一回では、背景としてCNCFのプロジェクトとは何であるのかを紹介し、Keycloakおよびコミュニティの記事執筆時点の最新動向を紹介します。
CNCFのプロジェクトとは
CNCFは、OSSおよびベンダ中立なクラウドネイテイブコンピューティングのハブとなる組織であり、グローバルの主要なベンダだけではなく、多くのエンドユーザー企業が加入しています。また、CNCFはKubernetesやPrometheusのようなクラウドネイテイブにとって重要なOSSをCNCF Projectとしてホストしています。
CNCFプロジェクトは、その成熟度に応じて、Sandbox、Incubating、Graduatedの3段階で管理されています(図1)。
Sandboxプロジェクトは実験的なOSSであり、図中に「Low barrier」と記載がある通り、広く門戸が開かれており、加入のための審査も緩やかです。一方で、Graduatedプロジェクトは、成熟した状態であり、広く世の中で利用されることが想定されるOSSです。KubernetesやPrometheusはこの段階にあります。
Graduatedの前段階のプロジェクトが、今回Keycloakが入ったIncubatingプロジェクトです。Incubatingプロジェクトは、今後Graduatedになることが想定されていることから、図中に「Significant barrier」とある通り、承認されるためには高いハードルがあります。OSSプロジェクトが、CNCFにIncubatingプロジェクトへの加入を申し込むと、DD(Due diligence)と呼ばれる調査がCNCFのTOC(Technical Oversight Committee、技術監督委員会)によって行われます。DDでは、コミュニティのガバナンス(メンテナが1社独占でないか等)、十分な利用実績があるか、コミュニティとしてセキュリティを確保するプロセスがあるか、等について調査されます。DDによる調査が終わるとTOCによる投票が行われ、承認されます。承認されると、TOCのsponsorという役割の人物の支援の下、Graduationに向かってコミュニティ側でプロセスの整備やそれに伴う開発を行っていきます。Graduationに向けて必要な活動の一例として、CNCF指定のセキュリティ監査会社による脆弱性やセキュリティ確保プロセスの監査を受け、その指摘に従い改善を行う、というものがあります。
Keycloakプロジェクトは、2018年7月ごろよりCNCF入りを目指した活動を行ってきました(最初の提案)。しかし、当初はメンテナがRed Hatの一社のみであったほか、前提となるAPサーバがKubernetes以前に開発された伝統的なJavaのAPサーバであることから、TOCの支持が得られず難航していました。その後、メンテナにRed Hat以外のメンバが加わり(日本からも日立製作所のメンバが加入)、APサーバについてもクラウドネイテイブ向けの軽量JavaサーバであるQuarkusに変更し、GitHubのスター数も1万を超え、複数の企業や団体による利用実績をアピールしてきました。その結果、2022年4月にIncubatingプロジェクトとして承認され、2022年4月のKubeCon+CloudNativeCon(KubeCon)EU 2023でもアナウンスされました(図2)
Keycloakの変更点
CNCF入りの過程でKeycloakにはさまざまな変更がありました。前回の連載以降で知っておくべき変更点を記します。
ベースのAPサーバがWildFlyからQuarkusに
前述したように、CNCFプロジェクトになるにあたり必要だった変更点です。KeycloakはJavaのアプリケーションとして実装されており、ベースのAPサーバは長らくWildFlyが使われていました。WildFlyは伝統的なJavaのAPサーバであり堅実ではあるのですが、Kubernetes普及以前の時代の実装であるため、コンテナが動的に立ち上がりスケールアウトする際に必要な高速な起動や少ないメモリ消費量というクラウドネイテイブの要件を満たすことが難しいという課題がありました。そのためWildFly上のKeycloakはクラウドネイテイブの要件を満たすことが難しく、CNCFのincubating projectの承認を得られない状況が続いてきました。
このような課題に対応するため、KeycloakのベースがQuarkusになっています。Quarkusは、クラウドネイテイブなJavaのフレームワークです。最初からKubernetes上のコンテナとして動作させる想定で開発が進んでおり、高速な起動時間と少ないメモリフットプリントを特徴としています。Keycloakでは、2022年2月のバージョン17よりWildFly版と並行して配布されるようになり、2022年11月リリースのバージョン20よりQuarkus版のみが配布されるようになっています。
筆者の環境で実際にWildFly版(Keycloak 15.0.1)とQuarkus版(Keycloak 21.1.2)を比較してみました。WildFly版は起動に約13.5秒かかり、起動時のメモリ消費が407MB程度だったのに対して、Quarkus版では起動に約8.7秒かかり、起動時のメモリ消費は234MB程度となりました。確かにQuarkus版では、起動が高速かつメモリ消費が減っていることが確認できました。
また、合わせて起動するためのコマンドが、startupコマンドから、kcコマンドに変更になっています。コマンドラインからの起動方法については、公式ドキュメントの「Getting Started/OpenJDK」から辿るとよいでしょう。
管理コンソール画面の変更
UX向上を目的として、Keycloakの管理コンソールが新たに作り直されており、2023年2月のバージョン21より新しいコンソール画面に差し替えられています。
例えば古いコンソール画面では、ブラウザの幅を狭くすると、図3のように本来左にあるメニューを表示できなくなり、使いづらくなります。
一方で、新しいコンソール画面では、ブラウザの幅を狭くしても、図4のように左にあるメニューを表示できます(Keycloakロゴの左の≡ボタンを押すとメニューを表示・非表示を切り替えられる)。
各種エンドポイントのURLの変更
Quarkus版のKeycloakでは、エンドポイントのURLが変更になっています。例えば、トークンエンドポイントのURLは、WildFly版Keycloakでは次のようになっていました。
http(s)://<ホスト>:<ポート>/auth/realms/<レルム>/protocol/openid-connect/token
Quarks版では、以下のように「auth」が削除されたものになっています。
http(s)://<ホスト>:<ポート>/realms/<レルム>/protocol/openid-connect/token
同様に他のエンドポイントでも「auth」が削除されています。WildFly版KeycloakをQuarkus版にバージョンアップする場合などに、WildFly版と同様のURLにするには、以下のように起動時のオプションに「--http-relative-path /auth」を付与します(Windows版での開発用の起動オプションの例)。
bin/kc.bat start-dev --http-relative-path /auth
クライアントアダプターの大幅な見直し
Keycloakには「クライアントアダプター」と呼ばれる、Keycloakを使ってシングルサインオンをしたいアプリケーションのためのライブラリが用意されていました。
しかし、クライアントアダプターを使わなくても他のライブラリや手段で代替できるということで、Keycloakのスコープから外すべきだという方向になり、2022年7月のバージョン19で多くのクライアントアダプターが廃止になりました。OpenID Connectでは、JavaScriptアダプターのみとなり、SAMLについては、WildFlyおよびJBoss EAP用アダプターのみとなりました。OpenID Connectについては、こちらのサイトに代替のライブラリが案内されています。代替がない場合は、リバースプロキシの利用などが必要になります。
Keycloakのコミュニティ
KeycloakのコミュニティもCNCFに入るまでの過程で整理され進化しています。記事執筆時点での状況を紹介します。
Keycloakの開発コミュニティ
Keycloakの開発コミュニティは、GitHubのサイト「https://github.com/keycloak」が中心です。Keycloakの開発について、以前はissue管理が別サイトで行われていたり、ドキュメント用のリポジトリが分かれていたりしていたのですが、記事執筆の時点では、Keycloak本体およびドキュメントの開発は、この中のkeycloakリポジトリに集約されています。Issueの報告はリポジトリの「issues」タブで行われ、開発のための議論も主に「discussions」タブで行われています。
Slackチャンネル
長らくユーザーや開発者の交流やディスカッションのために、以下のメーリングリストが使われてきました。
- Keycloak userメーリングリスト:Keycloakユーザーが質問するためのコミュニティ
- Keycloak developerメーリングリスト: 開発者の議論やアナウンスのためのコミュニティ
KeycloakがCNCFに入ったことに伴い、これらに加えて、CNCFのSlackに#keycloak、#keycloak-devチャンネルが開設されました。https://slack.cncf.io/のアカウントを作成し、「Cloud Native Computing Foundation」ワークスペースに移動し、「チャンネルを追加する」にて、これらのチャンネルに加入できます。記事執筆の時点では、メーリングリストに比べて多くの投稿があるようです。
OAuth SIG
Keycloakは以前の記事で紹介したように、FAPI-SIGというKeycloak開発コミュニティ内のSIG(Special Interest Group)にて、OAuth 2.0のセキュリティプロファイルであるFAPI(Financial Grade API)に対応してきました。2023年6月に、FAPI-SIGは、OAuth SIGと改名し、OAuthやOpenID Foundationに関連したセキュリティ仕様の実装全般に活動のスコープを広げています。毎月定例会が行われており、誰でも参加でき、前述のメーリングリストやSlackで開催のアナウンスがされています。記事執筆現在FAPIの新しいバージョンであるFAPI 2.0、アクセストークンに情報を含まないようにするreference token、アクセストークンの不正使用を防ぐOAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer(DPoP)、OpenID Connect for Identity Assurance(OIDC4IDA)などの開発が行われています。
コアな開発者とヘビーユーザー向けイベント:Keyconf
Keyconfという開発者とユーザーの交流イベントが開催されています。第一回は、2019年に開催されましたが、COVID-19の影響で開催が途絶え、第二回であるKeyconf 23が2023年6月にロンドンにて開催されました。OAuth SIGに関連するメンテナ、開発者、ヘビーユーザーが集まり、コアな議論が行われました。日本からも日立製作所所属のメンテナである乗松氏が参加し、OAuth SIGの開発内容について発表し議論を行いました。本イベントのレポートについては後日掲載する予定です。
KubeConでのセッション開催
KeycloakはCNCFのプロジェクトになったため、CNCFのフラッグシップイベントであるKubeConでセッション等交流の機会を持つことができるようになりました。CNCF入り直後の2023年4月に開催されたKubeCon EU 2023では、メンテナトラックにKeycloakプロジェクトも参加しています。メンテナトラックは、各プロジェクトの最新動向を共有するためのセッションです。KubeCon EU 2023のKeycloakのメンテナトラックについては、主要開発者であるAlexander Schwartz氏とメンテナの乗松氏の代理として筆者が担当し、Keycloakの基本的な機能の紹介とFAPI-SIGの活動を紹介しました。300人近くの現地での参加があり、セッション終了後も質疑も活発に行われました。資料はイベントのサイトに公開されています。
今後のKubeConでも、メンテナトラックやプロジェクトミーティング、ブース展示などを行おうとKeycloakコミュニティ内で議論が進んでいます。KubeConのプログラムに注目していただければと思います。
今回は、KeycloakのCNCF Incubatingプロジェクト入り後の状況を紹介しました。次回は、実際にKeycloakをコンテナ環境にデプロイし、CNCFのOSSにシングルサインオンする構築例を紹介します。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- CloudNative Days Tokyo 2023から、業務でのOSSコントリビューションのありかたとKeycloakについて解説したセッションを紹介
- Keycloakの最前線を体感できるイベント「Keyconf 23」レポート
- Cloud Native Community Japanキックオフミートアップ レポート
- 恒例となったOSSセキュリティ技術の勉強会、今回はSSOソフトウェア「Keycloak」に注目!
- FAPIとKeycloakの概要
- 注目のWebAuthnと公式より早いKeycloak最新動向を紹介!OSSセキュリティ技術の会 第5回勉強会
- 高まるOSSセキュリティへの関心に応え、認証に関する最新技術&情報を徹底紹介!
- コンテナ上のマイクロサービスの認証強化 ~StrimziとKeycloak~
- KeycloakによるAPIセキュリティの基本
- Keycloakのクライアントポリシー(Client Policies)