一つのOTPでWi-Fi、VPN、レジストリをまかなえない理由

シングルサインオンは一つのIDとより少ない問い合わせを約束しますが、その約束は三つ目のプロトコルで崩れます。罠は、一回の認証成功が他のあらゆるプロトコルに提示できるトークンを生み出すと考えることです。Wi-Fiの入構、VPNの入り口、コンテナレジストリはそれぞれ別の交換を行い、公開範囲も寿命も異なります。アカウントの共有はディレクトリの判断であり、資格情報の共有はプロトコルの判断であり、プロトコル同士が一致することはまれです。

三つの交換、三つの所有者

エンタープライズWi-Fiは802.1Xの中でEAP方式を実行し、通常はユーザーやデバイスについて独自の見解を持つRADIUSサービスが終端します。VPNゲートウェイは独自の対応フローで認証し、その後は独自の再認証タイマーを持つセッションを保持します。レジストリは未認証の要求に対して、トークンサービス、公開範囲、スコープを名指すチャレンジで応答し、クライアントは資格情報を短命のトークンと交換します。

これは一つのセッションの三つの見方ではありません。それぞれに独自の検証者、独自の寿命、独自の失効経路があり、だからこそディレクトリでのパスワード変更が一方を動かしたまま他方を壊すことがあります。これらはたまたまユーザーディレクトリを共有する三つの統合として扱ってください。

ブラウザのSSOが運ぶもの、運ばないもの

IDプロバイダーでのブラウザセッションは、そこへリダイレクトするアプリケーションがユーザーのすでに完了したログインを引き継ぐという点で、本当に有用です。それが機能するのは、そうしたアプリケーションが同じリダイレクトとトークンのプロトコルを話し、同じ公開範囲を受け入れるからです。EAPを話すサプリカントには従うべきリダイレクトがなく、レジストリのチャレンジを受け取るDockerクライアントはOIDCのIDトークンを求めていません。IDプロバイダーは、話すために作られたプロトコルにしか保証を与えられません。

どこを見ればよいか分かれば、障害はログで簡単に見つかります。IDプロバイダーはログイン成功を報告しているのにWi-Fiの関連付けはまだ失敗する、あるいはブラウザが一度も見なかったトークン交換の後にレジストリが401を返す、ということが起こります。二つの成功と一つの失敗は矛盾ではなく、別々の三つの認証なのです。

証明書が繰り返しのコードに代わる場面

管理されたデバイスでは、証明書ベースのEAPが人間の手順を残したままIDを保ちます——デバイスが証明書を提示し、RADIUSサービスが発行機関に対してそれを検証し、失効は共有の秘密ではなくその機関で行われます。代償はライフサイクルの作業であり、証明書は失効するのでその前に更新しなければなりません。

レジストリにも同等の分け方があります。対話的なユーザーは一度ログインし、得られたトークンを資格情報ヘルパーに保存させられますが、自動化には範囲を狭く絞ったサービス資格情報かワークロードIDを使うべきです。どちらも、人間のワンタイムコードをパイプラインにコピーしたものであってはなりません。ヘルパーは特定のレジストリ公開範囲向けのトークンを保存するので、設定ファイルを編集してVPNゲートウェイに向け直すことはできません。

docker login registry.example.com

問い合わせの回数ではなく、保守コストを比べてください

共有された資格情報は、失敗するまで作業が見えないために安く見えます。代わりに、登録、更新、失効、漏えい時の影響範囲、そして誰かが去るときに触れるシステムの数という、各選択肢が一年間に費やすものを数えてください。証明書の艦隊は構築に多くの費用がかかり規模を広げた運用では安くなりますが、コピーしたコードは始めるのに何もかからず解きほぐすのにすべてを費やします。

そのうえで、全体ではなく部分ごとに選んでください。Wi-Fiは証明書へ移れますし、VPNはMFA付きの対応SSOを保てますし、レジストリは明示的なスコープを持つトークンを使えます。それぞれについて所有者、公開範囲、スコープ、有効期限、失効経路を記録すれば、問い合わせは一度にどこにでもではなく、本来あるべき場所に落ちます。その記録は、監査人がどのシステムがまだパスワードを信頼しているかと尋ねたときの答えにもなります。