SCIM Bridgeは、デプロイした後も自社で面倒を見続けるサービスです。更新を怠ると、ある日を境にIDプロバイダーとの同期が止まります。止まっても既存のアカウントと情報に影響はありませんが、入社した人が使い始められず、退職した人が一時停止されない状態が続きます。このページでは、バージョンの確かめ方と廃止の通知、環境ごとの更新の手順、確認の間隔の調整、症状から原因を探す方法、ログの取り出し方を説明します。デプロイの手順はデプロイ先の選択と構成で扱います。
バージョンと廃止の通知を確かめる
ブラウザーでSCIM Bridgeのドメインを開くと、左上にバージョンが表示されます。<a href="https://releases.1password.com/provisioning/scim-bridge/" target="_blank">SCIM Bridgeのリリースノート</a>の最新版と比べてください。
使っているバージョンが廃止予定になると、メールで通知が届きます。通知から90日以内に更新しないと、既存のアカウントは使えたまま、IDプロバイダーとの同期だけが止まります。通知は既定で管理者グループのメンバーにだけ届きます。SCIM Bridgeの運用を別の担当者や共有のメールボックスが受け持つ場合は、1Password.comの統合で通知の宛先を管理する画面を開き、アドレスを加えて保存します。
【運用のポイント】 90日の猶予は通知が届いてから数えます。通知を見落とすと気付かないまま同期が止まるので、運用の担当者のアドレスを必ず宛先に加え、月に1回はバージョンを確かめる予定を入れてください。
環境ごとの更新の手順
更新では、コンテナイメージのタグ（1password/scim:v2.x.xの形）を最新のバージョンに変えます。
Azure Container Appsの場合
- Azure portalでSCIM Bridgeのコンテナアプリを開き、
ApplicationのContainersを選びます。 Image and tagのバージョンの部分を、最新のバージョンに書き換えます。Save as a new revisionを選び、デプロイが終わるまで待ちます。- SCIM Bridgeのドメインを開いてベアラートークンを入れ、左上のバージョンを確かめます。
Google Cloudのマーケットプレースの場合
Google Cloudのコンソールでクラスターの一覧を開き、SCIM Bridgeのクラスターを選んでConnect、Run in Cloud Shellの順に選びます。Cloud Shellでkubectl get deployを実行し、redis-masterで終わらない方のデプロイ名を控えます。既定ではop-scim-bridge-1です。
続けてkubectl set imageでイメージのタグを最新のバージョンに変えます。最後にkubectl patch applicationでアプリの記述のバージョンを書き換え、コンソールの表示を実際のバージョンに合わせます。既定の名前空間以外にデプロイした場合は、各コマンドに-n=で名前空間を付けます。
それ以外の環境の場合
DockerやKubernetes、AWSのECSで動かしている場合は、<a href="https://github.com/1Password/scim-examples" target="_blank">SCIM Bridgeのデプロイ例</a>の各環境の手順に従って、設定ファイルのタグを書き換えて適用します。DigitalOceanのマーケットプレースのアプリは、同じクラスターに新しい版を上書きでインストールします。完了まで最大10分かかります。
その場で更新できない場合は、デプロイし直します。SCIM Bridgeは状態を持たないので、止まっている時間を除けば、IDプロバイダーにもアカウントにも影響しません。デプロイし直す前に、IDプロバイダー側でプロビジョニングを一時停止してください。新しいIPアドレスに合わせてDNSレコードを直し、1Passwordのアカウントとの接続とIDプロバイダーの接続をやり直します。
確認の間隔を調整する
SCIM Bridgeは、参加した人を5分おきにまとめて確認します。初めて1Passwordを使う人が一斉に参加する時期など、待ち時間を縮めたい場合は、環境変数OP_CONFIRMATION_INTERVALに秒数を設定します。値は30秒以上にしてください。それより短いと確認が正しく動きません。
| 環境 | 設定の方法 |
|---|---|
| Azure Container Apps | ContainersのEnvironment variablesでAddを選び、名前と値を入れてSave as a new revisionを選ぶ |
| Kubernetes | kubectl set env deploy/op-scim-bridge OP_CONFIRMATION_INTERVAL=30 |
| Docker | docker service update op-scim-bridge_scim --env-add OP_CONFIRMATION_INTERVAL=30 |
設定した後は、SCIM Bridgeのドメインを開いて正しく動いていることを確かめます。
症状から原因を探す
原因が分からないときは、まずステータスページを開きます。SCIM Bridgeのドメインをブラウザーで開き、ベアラートークンで認証して、状態が全てConnectedになっているかを見ます。
参加した人が確認待ちのまま
人を作った後、確認する前にSCIM Bridgeが再起動すると、人の画面で確認待ちのまま残ります。5分以上たっても変わらない場合は、ステータスページを開きます。確認を担う処理が止まっていれば再開し、その人が確認されます。
ベアラートークンかscimsessionファイルをなくした
2つは暗号で結びついているので、片方だけを作り直すことはできません。統合のプロビジョニングの画面でクレデンシャルを作り直し、デプロイ先のscimsessionファイルとIDプロバイダーのベアラートークンを両方とも差し替えます。管理対象のグループの設定は残ります。
ログにセッションの作成の失敗が出る
ログにAuthWrap failed to generateNewSessionと出る場合は、Duoを使っているか、2要素認証を強制していることが原因です。プロビジョニングをオフにしてから、SCIM Bridgeをデプロイし直します。2要素認証の強制を後から始めるときは、この作業を計画に含めてください。
ファイアウォールのルールで拒否される
ログにYour current location or network is blocked by an account firewall ruleと出る場合は、1Passwordのファイアウォールのルールが接続を止めています。匿名のIPアドレスのルールでクラウド事業者を拒否していると、クラウドに置いたSCIM Bridgeもつながりません。送信元のIPアドレスが固定なら許可するルールを加え、固定でなければクラウド事業者を拒否の対象から外します。設定はファイアウォールルールによる制限で扱います。
メールアドレスを変えても確認のメールが届かない
新しいアドレスのドメインが、招待の画面の許可ドメインに入っているかを確かめます。
ヘルスモニタリングがつながらない
ChecklyからSCIM Bridgeへの通信を許可しているかを確かめます。統合のヘルスモニタリングの設定で、SCIM Bridgeのアドレスにパスを含めていないか（scim.example.com/app/statusではなくscim.example.com）も見ます。許可できない環境なら、ヘルスモニタリングをオフにします。
ログを取り出して問い合わせる
SCIM Bridgeのログには、エラーの内容と、アカウント、グループ、保管庫、人の識別子、SCIM Bridgeのドメイン、クラスターの情報が含まれます。シークレットや1Passwordのデータは含まれません。SCIM BridgeのIPアドレスなど、調査に不要な情報は送る前に消して構いません。
Azure Container Appsでは、コンテナアプリのLogsでクエリーを実行し、ExportでCSVに書き出します。Google Cloudでは、ワークロードの一覧からSCIM Bridgeのデプロイを開き、Logsタブで期間を7日にして、ActionsのDownload logsでJSON形式を選びます。書き出したファイルを添えて、1Passwordのビジネス向けのサポートに問い合わせます。IDプロバイダーの設定の問題なら、IDプロバイダーのサポートに問い合わせ、1Password側のサポートを同じやり取りに加えることもできます。