深夜の出来事:10個のアプリに10個の異なるパスワードがある時
運命の月曜日の夜、スマホが緊急メッセージの通知で激しく震えました。退職したばかりの管理者のアクセス権限を即座に削除する必要があったのです。しかし、いざ確認してみると愕然としました。GitLabに1つのアカウント、Wikiに1つのアカウント、さらにGrafanaやJenkins、そして大量の社内ダッシュボード. それぞれの場所に個別のデータベースユーザーが存在していたのです。
深夜、各サーバーにログインして一つずつアカウントをロックする作業を繰り返す中で、私は目が覚めました。集中型のアイデンティティプロバイダー(IdP)システムがなければ、これからもこうした長い夜を過ごすことになる。それが、私がKeycloakにたどり着いた理由です。
比較検討:Auth0、Okta、それともKeycloakを自前で運用する?
アイデンティティ管理(IAM)の課題を解決する際、通常3つの主な選択肢があります。私はコストからコントロール性まで、決定を下す前に各要素を慎重に検討しました。
1. 内部データベース(従来の方法)
- メリット: 導入が非常に速い。既存のDBに
usersテーブルを追加するだけ。 - デメリット: シングルサインオン(SSO)機能がない。従業員は数十個のパスワードを覚えなければならず、監査や権限削除が必要な際は各アプリを一つずつ回る必要があり、非常に手間がかかる。
2. クラウドIAM(Auth0、Okta、Firebase)
- メリット: 動作が非常にスムーズで、国際標準のセキュリティ。サーバーのメンテナンスを心配する必要がない。
- デメリット: ユーザー数が増えるとコストが跳ね上がる。Auth0は最初の7,000ユーザーまで無料だが、その後はコストが急激に上昇する。また、多くの企業がユーザーデータを内部インフラから外に出さないことを求めている。
3. セルフホスト型オープンソース(Keycloak、Casdoor)
- メリット: データを100%制御可能。OAuth2、OpenID Connect(OIDC)、SAML 2.0をフルサポート。最も重要なのはライセンス料がかからないこと。
- デメリット: バックアップの構築や、サーバーがダウンしないための管理を自分たちで行う必要がある。
なぜKeycloakがナンバーワンの選択肢なのか?
Keycloakを選んだのは、Red Hatが支援しているプロジェクトであり、非常に信頼性が高いためです。企業の既存のLDAPやActive Directoryと直接連携できます。GoogleやGitHubでログインさせたい場合も、Keycloakならあっという間に対応可能です。
Java(Quarkus)ベースで動作するため多少のリソースを消費しますが、その安定性と機能性はオープンソースの分野では敵なしです。
Docker Composeによるクイックデプロイ
本番環境での運用には、デフォルトのH2の代わりにPostgreSQLをデータベースとして使用します。以下は、システムが負荷に耐えられるように私が適用している構成です。
version: '3.8'
services:
postgres:
image: postgres:15
volumes:
- postgres_data:/var/lib/postgresql/data
environment:
POSTGRES_DB: keycloak
POSTGRES_USER: keycloak
POSTGRES_PASSWORD: ここに非常に強力なパスワードを入力
networks:
- keycloak_network
keycloak:
image: quay.io/keycloak/keycloak:24.0
command: start-dev
environment:
KC_DB: postgres
KC_DB_URL: jdbc:postgresql://postgres:5432/keycloak
KC_DB_USERNAME: keycloak
KC_DB_PASSWORD: ここに非常に強力なパスワードを入力
KC_HOSTNAME: sso.yourdomain.com
KEYCLOAK_ADMIN: admin
KEYCLOAK_ADMIN_PASSWORD: 管理者の超強力なパスワード
ports:
- "8080:8080"
depends_on:
- postgres
networks:
- keycloak_network
networks:
keycloak_network:
driver: bridge
volumes:
postgres_data:
ヒント: 「123456」のような安易なパスワードは絶対に設定しないでください。私はよく toolcraft.app/ja/tools/security/password-generator を使って32文字のランダムな文字列を生成しています。このツールはブラウザ上で完全に動作するため、開発者にとって非常に安全です。
Realm and Clientの設定:把握しておくべき概念
docker-compose up -d コマンドが完了すると、管理インターフェースにアクセスできるようになります。注意点として、クライアントアプリに master レルム(Realm)は絶対に使用しないでください。
新規Realmの作成
Realm(レルム)は1つの「王国」だと考えてください。データが混ざるのを防ぐため、プロジェクトや顧客ごとに個別のRealmを作成してユーザーを独立して管理すべきです。
Clientの設定
これは接続するアプリケーションを定義する場所です。例えば、私のダッシュボードアプリが https://dashboard.internal で動作している場合、Access Typeを confidential に設定してClient Secretを取得し、セキュリティを最高レベルに高めます。
実践で学んだ教訓(トラブルシューティング)
Keycloakの運用は、常に順風満帆というわけではありません。私は過去に以下のようなエラーに悩まされました。
- Nginxヘッダー: リバースプロキシを使用する場合、
X-Forwarded-Proto: httpsの設定が必須です。これがないと、Keycloakは接続が安全でないと判断し、トークンの発行を拒否します。 - 最小RAM: 512MBのVPSでKeycloakを動かそうとしないでください。スムーズに起動するには最低1GBのRAMが必要です。同時に50件ほどのログインリクエストがある場合、RAM使用量は1.5GBまで跳ね上がることがあります。
- タイムゾーンのズレ: サーバーとデータベースの時刻が5分以上ズレていると、OIDCトークンは生成された瞬間に期限切れになります。NTPをインストールして、正確な時刻を同期させてください。
まとめ
Keycloakは人事管理を楽にするだけでなく、システム全体のプロフェッショナル度を格段に向上させてくれました。今や、全アプリケーションの2要素認証(MFA)を有効にするのに、たった2クリックで済みます。
各アプリに個別にログイン処理を任せるのではなく、Keycloakのような「専門家」にその仕事を任せましょう。手動でのアカウント削除に怯えることなく、ぐっすり眠れる夜を過ごせるよう願っています。

