認証情報ローテーション Webhook の実装

エンドポイントの要件

次の構造を使用してエンドポイントを公開します。

PUT https://<your-registered-base-url>/v1/organizations/{organizationId}/projects/{projectId}/secrets

オンボード時に Atlas にベースURLを登録します。 organizationId と projectId のパスパラメータは、統合に関連付けられた Atlas組織とプロジェクトを識別します。オンボード時に Atlas と同意した場合は、別のURL構造を使用できますが、登録されたベースURLと必須識別子は明確なままである必要があります。

Atlas は、プロビジョニング中に確立されたインストールスコープの Bearer トークンを使用して各リクエストを認証します。

Authorization: Bearer <installation-access-token>
Content-Type: application/json

エンドポイントは、次の条件を満たす必要があります。

• すべてのリクエストでベアラー トークンを検証し、無効または期限切れのトークンは 401 Unauthorized で拒否します。

• トークンを機密情報として扱い、適切なアクセス制御を使用して保存します。

• 信頼できる認証局からの TLS 証明書とともに HTTPS を使用します。 Atlas はプレーンHTTP経由でエンドポイントを呼び出しません。自己署名証明書は本番環境ではサポートされていません。

リクエスト本文

リクエスト本文には、更新する認証情報のキーと値のペアが含まれています。

{
  "secrets": [
    {
      "name": "ATLAS_CONNECTION_STRING",
      "value": "mongodb+srv://user:pass@cluster.mongodb.net/"
    },
    {
      "name": "ATLAS_DB_USERNAME",
      "value": "app_user"
    },
    {
      "name": "ATLAS_DB_PASSWORD",
      "value": "rotated_password"
    }
  ],
  "partial": true
}

応答

再試行と冪等性

Atlas は失敗したリクエスト（5xx 応答またはネットワーク タイムアウト）を指数バックオフと限られた再試行回数で再試行します。

エンドポイントは冪等である必要があります。同じ ローテーションイベントに対して重複するリクエストを受け取る場合、同じ認証情報値を複数回適用してもエラーのない結果が得られます。

セキュリティ要件

上記の認証要件に加えて、エンドポイントは次の条件を満たす必要があります。

• 保管中の認証情報を暗号化する。

• アプリケーションログ、リクエストログ、エラー メッセージ、テレメトリ、またはプレーンテキスト構成ファイルに認証情報が表示されないようにします。

• 保存された認証情報へのアクセスは、それを必要とするシステムと担当者に制限します。

• 10 秒以内に応答します。新しい認証情報の保持にバックグラウンド処理が必要な場合は、リクエストを同期的に確認し、処理を非同期に完了します。

• インストール アクセス トークンが侵害されたと思われる場合は、同意された Atlas サポート プロセスに従ってください。

オンボード チェックリスト

Atlas がローテーションされた認証情報を統合に送信する前に、次の手順を実行する必要があります。

• オンボード時にコールバックベースURLを登録します。

• インストール アクセス トークンを確立して安全に保存します。

• ドキュメント認証情報名と更新セマンティクスが一致します。

• エンドポイントを HTTPS 経由でアクセスできるようにデプロイします。

• エンドポイントが期待されるステータス コードを返すことを確認します。

• 非本番環境でのエンドツーエンドのローテーションを非本番インストールで手動でテストします。

• 重複配信と再試行の動作をテストします。

追加リソース

• Atlas App Connections とアプリの統合

• データベースユーザーのライフサイクル