リーダーアカウントの構成

新しく作成されたリーダーアカウントには、アカウント全体の管理者として機能する1人のユーザーのみが含まれます。

アカウントを「ブートストラップ」(つまり、構成)するには、アカウント管理者は、ユーザー、カスタムロール(必要な場合)、仮想ウェアハウス、1つ以上の共有データベース(プロバイダーアカウントによって共有されたデータ用)を含むアカウントに、最小セットの追加オブジェクトを作成する必要があります。

このトピックでは、必須およびオプションの両方における、これらすべての構成タスクの概要を説明します。

注釈

アカウント管理者としてタスク2から4を完了する必要があります。残りのすべてのタスクは、他のユーザーに委任できます。

また、これらのタスクはすべて、プロバイダーアカウントではなく、リーダーアカウントで実行する必要があります。

このトピックの内容:

タスク1:アカウント管理者としてリーダーアカウントにログインする

サポートされているインターフェイスのいずれかを使用してリーダーアカウントにログインします(例:SnowSQL またはウェブインターフェイス)。

このトピックの手順では、SnowSQL 内、またはワークシート(ウェブインターフェイス内)を使用した SQL により、これらのタスクを実行していることを前提としています。ただし、タスクは、サポートされているSnowflakeインターフェイスで実行できます。

ちなみに

使用するロールとして ACCOUNTADMIN を設定することを忘れないでください。このロールは、ログイン中に設定することも、アクティブセッション後に設定することもできます。

これらのタスクを実行するためにワークシート(ウェブインターフェイス内)を使用している場合は、ワークシートのコンテキストでロールを設定します。

タスク2:カスタムロールを作成する(オプション)

ロールにより、リーダーアカウントのユーザーが実行できるタスクをきめ細かく制御できます。ロールを使用して次のことができます。

  • アカウントと共有するデータをクエリできるユーザーの指定。

  • 選択したユーザーによる仮想ウェアハウスの制御の許可。

  • 選択したユーザーによる管理者のタスクと責任の委任(必要な場合)。

各リーダーアカウントには、標準のシステム定義のロール(SYSADMIN、 SECURITYADMIN、 PUBLIC)が付与されています。これらの役割がアカウントで作成するユーザーのアクセス要件を満たさない場合、追加のカスタム役割を作成できます。

詳細については、 Snowflakeのアクセス制御 をご参照ください。

タスク3:ユーザーを作成する

リーダーアカウントにログインし、アカウントと共有するデータをクエリするユーザーを作成し、許可するように選択した他のタスクを実行します。

ユーザー作成プロセスの一環として、システム定義またはカスタム(作成した場合)のロールをユーザーに付与することを忘れないでください。ユーザーに割り当てる役割によって、アカウントで何ができるかが決まります。

詳細については、 CREATE USER および GRANT ROLE をご参照ください。

ちなみに

このトピックの残りのタスクはすべて、アカウント管理者が完了するか、アカウント内の他のユーザーに(権限とロールを介して)委任できます。

少なくとも、以下をお勧めします。

  • アカウント内で他のユーザーの作成、管理、およびオブジェクトアクセスの支援ができるように、少なくとも1人の他のユーザーに SECURITYADMIN ロールを付与します。

  • アカウント内(例:仮想ウェアハウス)で他のオブジェクトの作成および管理の支援ができるように、少なくとも1人の他のユーザーに SYSADMIN ロールを付与します。

タスク4:リソースモニターを作成する(オプション)

リーダーアカウントと共有するデータをクエリするには、仮想ウェアハウスが必要です。実行中、仮想ウェアハウスはクレジットを消費し、プロバイダーアカウントに請求されます。

リーダーアカウントの仮想ウェアハウスで毎月消費されるクレジットの量を制御したい場合は、1つ以上のリソースモニターを作成し、それらが制御するかどうかを指定します。

  • アカウント内のすべてのウェアハウス。

  • 個々のウェアハウス。

詳細については、 CREATE RESOURCE MONITOR をご参照ください。

注意

このタスクをスキップすることを選択した場合、リーダーアカウントのウェアハウスは毎月無制限のクレジットを消費でき、プロバイダーアカウントに請求されます。

タスク5:仮想ウェアハウスを作成する

共有データベース内のオブジェクトのクエリを有効にするには、少なくとも1つの仮想ウェアハウスを作成する必要があります。好きなだけ、または必要なだけウェアハウスを作成できます。ただし、リーダーアカウントのウェアハウスで消費されるすべてのクレジットについては、プロバイダーアカウントが責任を負う必要があることを念頭に、次の点を考慮します。

  • ウェアハウスのサイズを適切に設定して、目的のクエリパフォーマンスを目的のクレジット消費量と比較します。

  • ウェアハウスが使用されていないときは自動サスペンドに設定されていることを確認してください。

詳細については、 CREATE WAREHOUSE をご参照ください。

タスク6:アカウントと共有される各共有からデータベースを作成する

リーダーアカウントには、デフォルトではデータが含まれていません。プロバイダーアカウントから共有されたデータを使用するには、 CREATE DATABASE コマンドを使用して、アカウントと共有されている各共有からデータベースを作成する必要があります。データベースを作成する際に、リーダーアカウントの他のユーザーが共有データをクエリするときに参照する名前を指定します。

たとえば、プロバイダーアカウントの名前が ab12345 で、このリーダーアカウントにおいて share1 および share2 という名前の2つの共有を共有した場合、

CREATE DATABASE shared_db1 FROM SHARE ab12345.share1;

CREATE DATABASE shared_db2 FROM SHARE ab12345.share2;

タスク7:仮想ウェアハウスおよびデータベースの権限をロールに付与する

リーダーアカウントと共有されるデータのクエリを有効にするには、アカウント内のシステム定義またはカスタム(存在する場合)の他のロールに、次の権限を付与します。

必要に応じて、追加の権限を付与できます。ただし、上記の権限は、アカウント内の共有データベースをクエリするために必要な 最小 権限です。

たとえば、次のコマンドは、 shared_db1shared_db2 という名前の2つのデータベースと testing_vw という名前のウェアハウスに必要な権限を PUBLIC ロールに付与します。アカウント内のすべてのユーザーは自動的に PUBLIC ロールを持っているため、アカウント内のすべてのユーザーがウェアハウスを使用してデータベースをクエリできます。

GRANT USAGE ON WAREHOUSE testing_vw TO ROLE PUBLIC;

GRANT IMPORTED PRIVILEGES ON DATABASE shared_db1 TO ROLE PUBLIC;

GRANT IMPORTED PRIVILEGES ON DATABASE shared_db2 TO ROLE PUBLIC;

また、 testing_vw ウェアハウスに対する完全な権限を SYSADMIN ロールに付与して、ロールを持つユーザーによるウェアハウスの開始、停止、およびサイズ変更を有効にすることもできます。

GRANT ALL ON VIRTUAL WAREHOUSE testing_vs TO ROLE SYSADMIN;

詳細については、 GRANT <権限> ... TO ROLE をご参照ください。

タスク8:ユーザーをログインに招待してパスワードをリセットする

最後の構成タスクとして、作成したすべてのユーザーに、アカウントが使用可能であることを通知します。

これを行うための最速/最も簡単な方法は、 ALTER USER コマンドを使用して各ユーザーのパスワードをリセットすることです。これにより、ユーザーごとに一意の URL が生成され、ユーザーに送信/付与されます。URL を使用してパスワードを変更し、アカウントにログインします。

例:

ALTER USER ra_user1 RESET PASSWORD;

ALTER USER ra_user2 RESET PASSWORD;

重要

各 URL は 一度だけ 使用でき、4時間後に有効期限が 切れます 。ただし、ユーザーのパスワードは必要に応じて何度でもリセットできます。

詳細については、 ALTER USER をご参照ください。