こんにちは、エンジニアの chota60 です。いま私は、組織を横断した課題と向き合う Platform Unit という部署で、ギフティの様々なプロダクトで使える汎用認証基盤「WAYPoint1」の導入・運用保守・トラブルシューティングまで全てを担当しています。
WAYPoint は Keycloak を中心に据えて実装されていますが、Keycloak の運用をうまく回すのはなかなか簡単ではありません。この記事は、「いい感じに運用できていると思うからドヤりたい・・・!」という純粋な私欲でできています。Keycloak と向き合う誰かの支えになれれば、大変ありがたいです。
概要
この記事では、以下のトピックを取り扱います。 Keycloak とは何か?みたいな基本的な内容は取り扱いません。
- Keycloak の権限管理はどうして大変になっていくのか
- ラクに運用するにはどうしたら良いのか
成熟とのトレードオフで大変になっていく Keycloak 運用
始める時は一人から
どんなものでも、スタート地点は小規模なところからです。 ギフティにおける Keycloak 導入も、限られた数人だけがログインするような、小規模なアプリケーションとの連携から開始しました。 更新頻度が低く、用途も限られているため管理コストはかからず、一人でも問題なく運用できます。
しかし、組織内で Keycloak がより広く利用されるようになると、一人でできる限界を簡単に超えてしまいます。
増える client 、増える realm 、増えない管理者
Keycloak を活用するアプリケーションが発展していくと、主に二つの側面で複雑さが増していきます。
- アプリケーションを取り巻くエコシステムが発展することで、SSO (Single Sign On)できる client が増加する
- マルチテナンシーなアプリケーションが広く利用されていくことで、テナントの数だけ realm が増加する
この状況でも、管理者が一人のまま各種設定まで受け持つと、どうなるでしょうか?間違いなくパンクしてしまい、手が回らなくなってしまいます。
管理者だけで頑張らない!「委譲」のすすめ
こうした課題に対して WAYPoint では、client や user に関する権限をアプリケーション側の担当者に委譲することで対応してきました。 なお、realm の設定については前提知識が多く必要になるため、委譲のスコープからは外しています。
全部を管理者だけがやるのは、やめましょう!
例えば、リダイレクトを許可する URI などの client 設定は、利用するアプリケーションの都合で設定できた方が効率的です。Keycloak 管理者とのコミュニケーションが必要になってしまう場合、そのやり取りが開発速度に対するボトルネックになってしまいます。
そこで、アプリケーションの担当者に管理権限を委譲します。これによって、アプリケーション側の好きなタイミングで client の設定を変更することが可能になります。同時に Keycloak 管理者の負荷も軽減できて一石二鳥です。
WAYPoint ではこの権限委譲について、権限管理と認証方法の二つの面で工夫をしています。
権限は個別ではなくグループ単位で付与する
Keycloak の設定についての権限は、master realm の Role によって管理されています。
WAYPoint では、以下の方針で権限を管理しています。
- 各 realm の User Group を master realm に作成する
- 各 realm の管理権限を示す Role をそれぞれの User Group に付与する
- 最小権限の原則に則り、master realm の管理権限はどの User Group にも付与しない
このように設定することで、担当者は自分の所属する Group に関することだけしか変更できなくなり、意図せず他の Group を壊す心配をせずに作業することができます。この制限は管理者目線でも安心感に繋がります。
導入当初、Admin の権限(Role)は下図のように、それぞれの担当者(User)に付与していました。
しかし、この方針ではそれぞれの担当者が過剰な権限を有するため、意図しない設定変更の危険が伴います。
そこで、直接アサインするのではなく User Group を仲介して権限をアサインするようにしました。
こうすることで、担当者一人一人は自分の使いたい realm の設定だけを変更できるようになります。
また、一人の担当者が複数のアプリケーションを担当することもあります。その場合にも、所属する User Group を増やすことで容易に Role のアサインが可能です。
担当者の認証方法を限定する
権限を委譲する場合、アプリケーションの担当者は Keycloak 管理画面に master realm 上の User としてログインする必要があります。
一方、Keycloak の管理画面ではエンドユーザーの情報も含めて管理しています。したがって、User は可能な限り確実に身元の確認を行う必要があります。そこで、 ID 連携の仕組みを取り入れています。
ギフティでは、グループウェアとして Google Workspace を利用しています。Google Workspace と ID 連携することで確実に身元を保証することができます。 また、Keycloak ではユーザーについてパスワードを設定しない限り、パスワードによるログインはできません。
WAYPoint の管理画面ではこれらの前提を組み合わせ、アプリケーションの担当者は Google Workspace との ID 連携でしかログインできないようにログイン方法を限定しています。確実に身元が保証された User のみが、管理画面を利用することができます。
パスワードを介さないことによる利便性と、ID 連携によるセキュリティ向上の両側面でメリットのあるお得な仕組みにできました。
合わせ技によって権限管理を安全にラクにする
WAYPoint では下記の合わせ技により、Keycloak の運用を安全に、かつラクにしています。
- User Group に管理用の Role をアサインすることで、アプリケーション担当者の権限管理を容易にする
- アプリケーションの担当者に、管理画面にログインするためのパスワードを設定させない
- 管理画面へのログイン方法を、Google Workspace を用いたログインのみに制限する
まとめ
- Keycloak は活用の幅が広がっていくほど、管理上の課題が大きくなっていきます
- 管理者がパンクしてしまうと、何も進まなくなってしまうので、無理が起こらないように構えておきたいです
- 管理権限を安全に委譲することで、管理者の心配事を大きく軽減することができます
- 積極的にありものの仕組みを活用して、ラクをしていきましょう!
To Be Continued...
ここまで紹介してきた権限委譲の仕組みによって、非常に快適に管理権限の運用ができています。 しかし、このやり方にも手作業によるケアレスミスのリスクや設定に関する知識のサイロ化という課題が残っています。
現在この課題に対する対策として、Terraform provider for Keycloak の活用を検討しています。 この Provider を使うことで、realm の設定や client の設定をコードで管理することが可能になるため、うまくいけば適切に課題を解消できるはずです・・・!
そんな未来が実現したらまたお会いしましょう!それでは〜!ノシ
- 詳しくは WAY Pointってなんですか? を見ていただければ。↩