Skip to main content
web サービス(login-register モジュール)は、メールログイン、LDAP ログイン、登録、パスワードリセットの際に reCAPTCHA v2(invisible)を要求します。キーの作成方法と各設定の役割は reCAPTCHA を参照してください。このページでは、それを Kubernetes に設定する方法を説明します。

設定

1

サイトキーを ConfigMap に設定する

サイトキーは公開情報です。すべてのログインページに表示されます。
2

シークレットキーとデバイス履歴キーを Secret に設定する

両方のキーを一緒に設定してください。サイトキーがあってシークレットキーがない場合、すべてのチェックが失敗し、誰もパスワードでのログイン、登録、パスワードのリセットができなくなります。DEVICE_HISTORY_SECRET は 64 文字の 16 進数である必要があります。コンテナはこれを自動生成しません。
3

適用して再起動する

次に、すべての Pod がエンドポイントに到達できることを確認します。Pod は接続試行ごとに約 1 秒で諦め、チェックを実行できなかったログインはエラーで失敗します。

複数のレプリカ

すべてのレプリカで DEVICE_HISTORY_SECRET を共有する必要があります。Secret に格納していれば共有されます。値が異なると、あるレプリカで通過したブラウザが別のレプリカで再びキャプチャを求められます。レート制限は、すべてのレプリカをまたいで Redis でカウントされます。

Kubernetes でのテスト結果

Google の検証エンドポイントのモック(overleaf-certs の NODE_EXTRA_CA_CERTS を通じて信頼)に対して、Kubernetes 1.37 上で reCAPTCHA のエンドツーエンドテストに合格しました(13 ケース)。レプリカ 1 つでは、ログイン、登録、パスワードリセットのそれぞれについて、キャプチャなしまたは失敗したキャプチャでは拒否され、通過したキャプチャでは受け付けられること、DEVICE_HISTORY_SECRET によるデバイス履歴でブラウザがキャプチャをスキップできること、CAPTCHA_TRUSTED_USERS を確認しました。HAProxy の背後の 3 つのレプリカでは、キャプチャ付きの LDAP ログインを確認しました。
最終更新日 2026年11月2日