Keycloak を利用した認証基盤の統合 – LDAP / Nextcloud / Kubernetes をどうつなぐか

自宅環境で複数のサービスを運用していると、認証情報の管理がだんだん面倒になります。Samba、Nextcloud、Kubernetes 上のアプリケーション、監視ツール、管理画面など、それぞれが別々にユーザーを持ち始めると、どこが正本なのか分からなくなります。

そこで考えたのが、Keycloak を利用した認証基盤の統合です。ただし、これは単に Keycloak を導入すれば認証がすべて綺麗になる、という話ではありません。LDAP、SAML、OIDC、Samba、Nextcloud、Kubernetes にはそれぞれ得意な範囲と制約があります。

重要なのは、認証方式の優劣を決めることではなく、どのサービスが何を担当し、どの経路で認証情報を参照するのかを確認することです。Keycloak は万能の認証箱ではなく、責任分界を見えるようにするための中核として扱う方が自然です。

前提となる自宅環境

私の環境では、ファイルサーバーとして Samba を利用しており、認証のバックエンドには LDAP を使っています。一方で、ファイルサーバーのフロントエンドとして Nextcloud も利用しており、こちらは別の認証管理になりがちです。

さらに Kubernetes 上に各種アプリケーションを展開していくと、アプリケーションごとにローカルユーザーを持つ構成は避けたくなります。ユーザー作成、削除、パスワード変更、権限管理が分散すると、運用が破綻しやすいからです。

• Samba は LDAP を参照してファイル共有の認証を行う
• Nextcloud はブラウザログインと WebDAV で認証経路が分かれやすい
• Kubernetes 上のアプリケーションは SAML / OIDC 連携しやすいものが多い
• Kubernetes 自体の RBAC や ServiceAccount はアプリ SSO とは別に考える
• ユーザー情報の正本をどこに置くかを明確にする必要がある

Keycloak をどこに置くか

Keycloak は、LDAP の代わりにすべての認証情報を持たせるというより、認証連携のハブとして置くのが自然です。

LDAP をユーザー情報の正本として残し、Keycloak は LDAP を参照する。アプリケーション側は Keycloak と SAML / OIDC で連携する。こうすると、古い LDAP 前提のサービスと、現代的な SSO 前提のアプリケーションを橋渡しできます。

要素	位置づけ	注意点
LDAP	ユーザー、グループ、既存の UNIX / Samba 認証の正本	OS 認証や Samba 連携では引き続き重要
Keycloak	LDAP を参照し、SAML / OIDC / OAuth 2.0 の認証連携を提供するハブ	正本を持つのか、LDAP 参照にするのかを決める
Samba	LDAP を参照し、ファイル共有の認証を行う	SAML / OIDC で直接置き換える領域ではない
Nextcloud	ブラウザログインは SAML / OIDC 連携、WebDAV は別経路として扱う	アプリパスワードやクライアント認証を考慮する
Kubernetes 上のアプリケーション	Keycloak を IdP として SSO 連携する	アプリの認証と Kubernetes の RBAC は分けて考える

LDAP を捨てる話ではない

ここで大事なのは、LDAP を古いものとして捨てる話ではないということです。LDAP は、OS 認証、Samba、グループ管理、既存のディレクトリ参照では今でも強い役割を持ちます。

一方で、Web アプリケーションのログイン、SSO、トークンベースの認証、外部 IdP 連携では、SAML や OIDC の方が扱いやすい場面があります。

つまり、LDAP と SAML / OIDC は単純な上下関係ではありません。LDAP はディレクトリとアカウントの正本、SAML / OIDC はアプリケーション連携のプロトコルとして分けて考えるべきです。

認証、認可、ユーザー管理を分ける

認証基盤を設計する時に混ざりやすいのが、認証、認可、ユーザー管理です。Keycloak を入れると、この 3 つをすべて解決してくれるように見えますが、実際にはサービスごとに残る責務があります。

観点	意味	例
ユーザー管理	ユーザーやグループの正本をどこに置くか	LDAP、Keycloak、アプリ内ユーザー
認証	誰であるかを確認すること	LDAP bind、SAML、OIDC、アプリパスワード
認可	何を許可するかを決めること	Nextcloud の共有権限、Kubernetes RBAC、アプリ内ロール
監査	誰がいつ何をしたかを見ること	Keycloak ログ、アプリログ、監査ログ

ここを分けないと、SSO できたから統合完了、という雑な理解になりがちです。実際には、ログインできることと、適切な権限で操作できることは別です。

SAML / OIDC が常に高セキュリティというわけではない

SAML や OIDC を使えば、それだけで LDAP より高セキュリティになる、という理解は雑です。セキュリティはプロトコル名ではなく、設計、実装、運用、鍵管理、セッション管理、権限設計、監査によって決まります。

SAML / OIDC は、パスワードを各アプリケーションに持たせない、SSO を実現する、MFA や条件付きアクセスを集約する、といった点で強力です。しかし、IdP が単一障害点になったり、属性マッピングを誤ったり、ログアウトやセッション管理が曖昧になったりするリスクもあります。

したがって、Keycloak を導入する目的は、認証方式を新しくすることではなく、責任分界を明確にすることです。

Nextcloud では WebDAV を別に考える必要がある

Nextcloud は、ブラウザからのログインだけを見れば SAML / OIDC 連携しやすいアプリケーションです。しかし、WebDAV、デスクトップクライアント、モバイルアプリ、外部ストレージ連携まで含めると、認証経路が単純ではありません。

ブラウザログインを SSO 化しても、WebDAV が同じ体験で動くとは限りません。アプリパスワード、基本認証、クライアント側の対応状況、セッションの扱いを確認する必要があります。

そのため、Nextcloud の認証統合では、ブラウザログインの綺麗さだけでなく、実際に使うアクセス経路をすべて洗い出すことが重要です。

Kubernetes 上に Keycloak を置く意味

Keycloak を Kubernetes 上に展開すると、アプリケーション基盤としての一貫性は高まります。Ingress、証明書、Secret、DB、バックアップ、監視を Kubernetes 側の運用モデルに寄せられます。

一方で、認証基盤を Kubernetes 上に置くということは、Kubernetes 自体が不安定な時に認証基盤も影響を受ける可能性があるということです。Keycloak は便利なアプリケーションであると同時に、他のサービスの入口にもなります。

そのため、Keycloak をどの namespace に置くか、DB をどう保護するか、バックアップをどう取るか、証明書をどう更新するか、障害時にローカル管理者で復旧できるかを考える必要があります。

設計として決めるべきこと

Keycloak を中心に認証基盤を統合する場合、最初に決めるべきことは設定手順ではありません。責務と正本です。

• ユーザー情報の正本を LDAP に置くのか、Keycloak に移すのか
• グループやロールをどこで管理するのか
• Samba のような LDAP 前提サービスをどう扱うのか
• Nextcloud の WebDAV やアプリパスワードをどう扱うのか
• Kubernetes 上のアプリケーションにどの claim を渡すのか
• Kubernetes の RBAC とアプリケーション認可をどう分けるのか
• IdP 障害時に管理者が復旧できる経路を残すのか

このあたりを曖昧にしたまま Keycloak を導入すると、認証経路が増えただけで、かえって管理が複雑になります。

関連記事

• Nextcloud SAML 認証で WebDAV が問題になる理由 – SSO とアプリパスワードを分けて考える
• LDAP より SAML/OIDC が高セキュリティという幻想 – 認証方式は適材適所で選ぶ
• Apache Directory Studio は開発終了なのか – LDAP クライアントの現状と使いどころ
• Ubuntu 26.04 SSSD による LDAP 連携
• Samba の SID と認証の確認
• Mac のローカルストレージをどう考えるか – Samba / Nextcloud 時代のファイル運用

まとめ

Keycloak を利用した認証基盤の統合は、単に SSO を導入する話ではありません。LDAP、Samba、Nextcloud、Kubernetes 上のアプリケーションを、それぞれの責務に分けて接続する設計です。

LDAP はユーザー情報や既存認証の正本として強く、SAML / OIDC は Web アプリケーション連携や SSO に向いています。Keycloak は、その間をつなぐ認証連携のハブとして使えます。

ただし、Keycloak を入れれば自動的に安全になるわけではありません。どこが正本で、どこが認証し、どこが認可し、障害時にどう復旧するのかを明確にして初めて、認証基盤として意味を持ちます。

関連する記事