リーダーアカウントの構成¶
新しく作成されたリーダーアカウントには、アカウント全体の管理者として機能する1人のユーザーのみが含まれます。
アカウントを「ブートストラップ」(つまり、構成)するには、アカウント管理者は、ユーザー、カスタムロール(必要な場合)、仮想ウェアハウス、1つ以上の共有データベース(プロバイダーアカウントによって共有されたデータ用)を含むアカウントに、最小セットの追加オブジェクトを作成する必要があります。
このトピックでは、必須およびオプションの両方における、これらすべての構成タスクの概要を説明します。
注釈
アカウント管理者としてタスク2から4を完了する必要があります。残りのすべてのタスクは、他のユーザーに委任できます。
また、これらのタスクはすべて、プロバイダーアカウントではなく、リーダーアカウントで実行する必要があります。
このトピックの内容:
タスク1: アカウント管理者としてリーダーアカウントにログインする¶
サポートされているインターフェイス(例: SnowSQL またはウェブインターフェイス)のいずれかを使用してリーダーアカウントにログインします。
このトピックの手順では、SnowSQL 内、またはワークシート(ウェブインターフェイス内)を使用した SQL により、これらのタスクを実行していることを前提としています。ただし、タスクは、サポートされているSnowflakeインターフェイスで実行できます。
Tip
使用するロールとして ACCOUNTADMIN を設定することを忘れないでください。このロールは、ログイン中に設定することも、アクティブセッション後に設定することもできます。
これらのタスクを実行するためにワークシート(ウェブインターフェイス内)を使用している場合は、ワークシートのコンテキストでロールを設定します。
タスク2: カスタムロールを作成する(オプション)¶
ロールにより、リーダーアカウントのユーザーが実行できるタスクをきめ細かく制御できます。ロールを使用して次のことができます。
アカウントと共有するデータをクエリできるユーザーの指定。
選択したユーザーによる仮想ウェアハウスの制御の許可。
選択したユーザーによる管理者のタスクと責任の委任(必要な場合)。
各リーダーアカウントには、標準のシステム定義のロール(SYSADMIN、 SECURITYADMIN、 PUBLIC)が付与されています。これらの役割がアカウントで作成するユーザーのアクセス要件を満たさない場合、追加のカスタム役割を作成できます。
詳細については、 アクセス制御の概要 をご参照ください。
タスク3: ユーザーを作成する¶
リーダーアカウントにログインし、アカウントと共有するデータをクエリするユーザーを作成し、許可するように選択した他のタスクを実行します。
ユーザー作成プロセスの一環として、システム定義またはカスタム(作成した場合)のロールをユーザーに付与することを忘れないでください。ユーザーに割り当てる役割によって、アカウントで何ができるかが決まります。
詳細については、 CREATE USER および GRANT ROLE をご参照ください。
Tip
このトピックの残りのタスクはすべて、アカウント管理者が完了するか、アカウント内の他のユーザーに(権限とロールを介して)委任できます。
少なくとも、以下をお勧めします。
アカウント内で他のユーザーの作成、管理、およびオブジェクトアクセスの支援ができるように、少なくとも1人の他のユーザーに SECURITYADMIN ロールを付与します。
アカウント内(例:仮想ウェアハウス)で他のオブジェクトの作成および管理の支援ができるように、少なくとも1人の他のユーザーに SYSADMIN ロールを付与します。
タスク4: リソースモニターを作成する(オプション)¶
リーダーアカウントと共有するデータをクエリするには、仮想ウェアハウスが必要です。実行中、仮想ウェアハウスはクレジットを消費し、プロバイダーアカウントに請求されます。
リーダーアカウントの仮想ウェアハウスで毎月消費されるクレジットの量を制御したい場合は、1つ以上のリソースモニターを作成し、それらが制御するかどうかを指定します。
アカウント内のすべてのウェアハウス。
個々のウェアハウス。
詳細については、 CREATE RESOURCE MONITOR をご参照ください。
注意
このタスクをスキップすることを選択した場合、リーダーアカウントのウェアハウスは毎月無制限のクレジットを消費でき、プロバイダーアカウントに請求されます。
タスク5: 仮想ウェアハウスを作成する¶
共有データベース内のオブジェクトのクエリを有効にするには、少なくとも1つの仮想ウェアハウスを作成する必要があります。好きなだけ、または必要なだけウェアハウスを作成できます。ただし、リーダーアカウントのウェアハウスで消費されるすべてのクレジットについては、プロバイダーアカウントが責任を負う必要があることを念頭に、次の点を考慮します。
ウェアハウスのサイズを適切に設定して、目的のクエリパフォーマンスを目的のクレジット消費量と比較します。
ウェアハウスが使用されていないときは自動中断に設定されていることを確認してください。
詳細については、 CREATE WAREHOUSE をご参照ください。
タスク7: 仮想ウェアハウスおよびデータベースに対する権限をロールに付与する¶
データプロバイダーは、データベースロールを介してオブジェクトに対する権限を共有に付与してから、データベースロールを共有に付与する(オプション1)か、 あるいは オブジェクトに対する権限を共有に直接付与する(オプション2)かの いずれか により、オブジェクトを共有に追加することを選択できます。このセクションの手順は、データベースプロバイダーが選択したオプションによって異なります。
- オプション1:
リーダーアカウントと共有されているデータのクエリを有効にするには、アカウント内の適切なロールを使用して、アカウント内のビジネス機能と連携する共有内のデータベースロールを付与します。たとえば、アカウント内のすべてのユーザーと共有する
shared_db1.dr1
という名前のデータベースロールが共有に含まれているとします。この場合は、データベースロールを PUBLIC システムロールに付与します。GRANT DATABASE ROLE shared_db1.dr1 TO ROLE PUBLIC;
- オプション2:
リーダーアカウントと共有されるデータのクエリを有効にするには、アカウント内のシステム定義またはカスタム(存在する場合)の他のロールに、次の権限を付与します。
タスク6: アカウントと共有される各共有からデータベースを作成する の共有から作成された各データベースに対する IMPORTED PRIVILEGES (このトピック内)。
たとえば、次のコマンドは、
shared_db1
とshared_db2
という名前の2つのデータベースとtesting_vw
という名前のウェアハウスに必要な権限を PUBLIC ロールに付与します。アカウント内のすべてのユーザーは自動的に PUBLIC ロールを持っているため、アカウント内のすべてのユーザーがウェアハウスを使用してデータベースをクエリできます。GRANT IMPORTED PRIVILEGES ON DATABASE shared_db1 TO ROLE PUBLIC; GRANT IMPORTED PRIVILEGES ON DATABASE shared_db2 TO ROLE PUBLIC;
さらに、クエリを実行するために作成した仮想ウェアハウスに対する USAGE 権限を付与します。
GRANT USAGE ON WAREHOUSE testing_vw TO ROLE PUBLIC;
必要に応じて、追加の権限を付与できます。ただし、上記の権限は、アカウント内の共有データベースをクエリするために必要な 最小 権限です。
また、 testing_vw
ウェアハウスに対する完全な権限を SYSADMIN ロールに付与して、ロールを持つユーザーによるウェアハウスの開始、停止、およびサイズ変更を有効にすることもできます。
GRANT ALL ON WAREHOUSE testing_vs TO ROLE SYSADMIN;
詳細については、 GRANT <権限> をご参照ください。
タスク8: ユーザーをログインに招待してパスワードをリセットする¶
最後の構成タスクとして、作成したすべてのユーザーに、アカウントが使用可能であることを通知します。
これを行うための最速/最も簡単な方法は、 ALTER USER コマンドを使用して各ユーザーのパスワードをリセットすることです。これにより、ユーザーごとに一意の URL が生成され、ユーザーに送信/付与されます。URL を使用してパスワードを変更し、アカウントにログインします。
例:
ALTER USER ra_user1 RESET PASSWORD; ALTER USER ra_user2 RESET PASSWORD;
重要
各 URL は 一度だけ 使用でき、4時間後に有効期限が 切れます 。ただし、ユーザーのパスワードは必要に応じて何度でもリセットできます。
詳細については、 ALTER USER をご参照ください。