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

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

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

重要なのは、認証方式の優劣を決めることではなく、どのサービスが何を担当し、どの経路で認証情報を参照するのかを整理することです。

前提となる自宅環境

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

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

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

Keycloak をどこに置くか

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

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

要素	位置づけ
LDAP	ユーザー、グループ、既存の UNIX / Samba 認証の正本として扱う。
Keycloak	LDAP を参照し、SAML / OIDC / OAuth 2.0 の認証連携を提供する。
Samba	従来通り LDAP を参照し、ファイル共有の認証を行う。
Nextcloud	ブラウザログインは SAML / OIDC 連携を検討し、WebDAV は別途制約を確認する。
Kubernetes 上のアプリケーション	Keycloak を IdP として SSO 連携する。

LDAP を捨てる話ではない

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

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

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

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 上のアプリケーションにどのクレームを渡すのか
• IdP 障害時に管理者が復旧できる経路を残すのか

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

関連記事

• LDAP より SAML/OIDC が高セキュリティという幻想 – 認証方式は適材適所で選ぶ
• Nextcloud SAML 認証で WebDAV が問題になる理由
• Zabbix で複数 LDAP 連携を使う時の注意点 – JIT プロビジョニングと認証設計
• Ubuntu 22.04 Samba 構築 – LDAP 認証と SID を整理する
• Ubuntu 26.04 SSSD による LDAP 連携

まとめ

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

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

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