Docs Menu

Atlas Administration API 認証

Atlas Administration APIへの認証には、次の 2 つの方法のいずれかを使用できます。

API キー
サービス アカウント(プレビュー)

HTTPダイジェスト認証を使用する Atlas へのレガシー認証方法。

業界標準の OAuth 2.0 プロトコルとクライアント認証情報フローを使用して Atlas に認証する新しい方法。現在はプレビュー段階です

APIキーには、公開キーと秘密キーの 2 つの部分があります。この 2 つの部分が、Atlas にAPIリクエストを行う際に、ユーザー名およびパスワードと同じ機能を果たします。

サービス アカウントを使用すると、権限を管理し、アクセス トークンを作成できます。 サービス アカウントには、アクセス トークンを作成するためのユーザー名とパスワードとして機能するクライアントIDとシークレットがあります。 アクセス トークンを使用すると、Atlas にAPIリクエストを行うことができます。

Atlas は、ナンスと呼ばれる一意の値を使用して公開キーと秘密キーをハッシュします。ナンスは HTTP ダイジェスト認証仕様に従って、短期間のみ有効です。これはリプレイ攻撃を防ぐためのもので、ナンスをキャッシュして永久に使用することはできません。

サービス アカウントを作成したら、そのクライアントIDとシークレットを使用してアクセス トークンを生成し、 APIリクエストを認証します。アクセス1 3600トークンは、OAuth2.0 仕様に従って 時間( 秒)のみ有効です。アクセス トークンの有効期限が切れると、リプレイ攻撃を防止できます。この場合、リークされたアクセス トークンは時間制限なしで使用できます。

Atlas ロールは、 APIキーが実行できる操作を制限します。APIキーで、エラーなくAPIエンドポイントを呼び出せるようにするには、ユーザーの場合と同様にAPIキーにロールを付与する必要があります。

Atlas ロールは、サービス アカウントがアクセス トークンを使用して実行できる操作を制限します。アクセス トークンで、エラーなくAPIエンドポイントを呼び出せるようにするには、ユーザーの場合と同様に、サービス アカウントにロールを付与する必要があります。

Atlas は多くのリソースをプロジェクトにバインドします。 多くのAPIリソースURLは /api/atlas/<version>/groups/<GROUP-ID>/の形式に従います。ここで、<GROUP-ID> はプロジェクトIDです。これらのリソースの場合、 APIキーはプロジェクトをホストする組織のメンバーである必要があります。それ以外の場合、Atlas は401 エラーで応答します。組織レベルのAPIキーにプロジェクトへのアクセス権を付与するには、「プロジェクトへの既存の組織アクセスの割り当て 」を参照してください。

Atlas は多くのリソースをプロジェクトにバインドします。 多くのAPIリソースURLは /api/atlas/<version>/groups/<GROUP-ID>/の形式に従います。ここで、<GROUP-ID> はプロジェクトIDです。これらのリソースでは、サービス アカウントはプロジェクトをホストする組織のメンバーである必要があります。 それ以外の場合、Atlas は401 エラーで応答します。組織レベルのサービス アカウントにプロジェクトへのアクセス権を付与するには、「 既存の組織のアクセス権をプロジェクトに割り当て 」を参照してください。

各APIキーは 1 つの組織にのみ属しますが、その組織内の任意の数のプロジェクトにAPIキーによるアクセスを許可できます。

各サービスアカウントは 1 つの組織のみに属しますが、その組織内の任意の数のプロジェクトへのアクセスをサービスアカウントに許可できます。

APIキーを使用して Atlas UIから Atlas にログすることはできません。

サービスアカウントまたはそのアクセス トークンを使用して、Atlas UI から Atlas にログインすることはできません。

Atlas Administration APIへの認証に希望する方法を設定するには、「 組織へのプログラムによるアクセスの付与 」を参照してください。

Tip

以下も参照してください。