Looker 22.16 のドキュメントを表示しています。最新のドキュメントはこちらをご覧ください。

新しい Looker インスタンスの自動プロビジョニング

オプションとして、新しい Looker インスタンスの起動時に、ライセンスキー、ホスト URL、初期ユーザーアカウントを使用して、インスタンスを自動的にプロビジョニングできます。

新しいインスタンスでメールユーザーを使用して自動プロビジョニングする

最初の起動時に、Looker は JAR ファイルが存在する looker ディレクトリにある provision.yml という名前のファイルをスキャンします。このファイルの形式は次のとおりです。

license_key: "1234-5678-ABCD-EFGH-IJKL"
host_url: "https://looker.mycompany.com"
user:
  first_name: "Katie"
  last_name: "Woolsey"
  email: "kwoolsey@benaventi.com"
  password: "password123"

Looker インスタンスが新規で、まだ設定されていない場合は、指定されたライセンスキーとユーザーアカウントによって提供された情報がプロビジョニングされます。

Looker がすでにプロビジョニングされている場合は、現在設定されているライセンスキーとホスト URL がライセンスキーとホスト URL 値よりも優先されます。ユーザー情報は無視されます。これは、Looker のステージングインスタンスを、本番環境のインスタンスの内部データベースの新しいコピーで更新しながら、ステージングサーバー用に別のライセンスキーと URL を維持する場合に便利です。

新しいインスタンスを API ユーザーで自動的にプロビジョニングする

新しい Looker インスタンスの起動時に、初期 API ユーザーをプログラムでプロビジョニングできます。API ユーザーまたはメールユーザーをプロビジョニングできますが、Looker は API ユーザーとメールユーザーの両方を同時にプロビジョニングすることはできません。

API 認証情報の生成

API ユーザーをプロビジョニングするには、Looker が読み取ってデータベースに保存するクライアント ID とクライアントシークレットを生成します。これらの認証情報の要件は次のとおりです。

クライアント ID は 20 文字で指定してください。
クライアントシークレットは 24 文字で指定してください。
どちらの文字列も POST リクエストの本文に含めることができるため、英数字のみを使用することをおすすめします。

たとえば、Looker は次のコードを使用してプログラムで認証情報を生成します。

require 'securerandom'

TOKEN_SYMBOLS = "bcdfghjkmnpqrstvwxyzBCDFGHJKMNPQRSTVWXYZ23456789".freeze

def generate_token(size)
  Array.new(size).map { TOKEN_SYMBOLS[SecureRandom.random_number(TOKEN_SYMBOLS.size)] }.join
end

上記のコードでは、あいまいな文字を回避して、文字列のエラーの発生を減らします。

openssl コマンドを使用して、適切な文字列を生成することもできます。

openssl rand -hex 10

openssl コマンドの末尾の数字は文字列のバイト数であるため、クライアント ID には 10、クライアントシークレットには 12 を使用します。

API ユーザーのプロビジョニング

起動時に API ユーザーをプロビジョニングするには、looker ファイルにライセンスキーとホスト URL を含む provision.yml ファイルを用意します。例:

license_key: "1234-5678-ABCD-EFGH-IJKL"
host_url: "https://looker.mycompany.com"

looker ディレクトリに、API ユーザー情報を含む権限 0600 を含む api-provision.yml という名前のファイルを作成します。例:

user:
  first_name: "Katie"
  last_name: "Woolsey"
  client_id: "M9hZb8vRh9bSZzdPxw42"
  client_secret: "NMnqBVbHqPsPzTvbZk6xZfV3"

Looker インスタンスで処理が行われ、データベース内にユーザーが作成されると、起動時にこのファイルが削除されるため、認証情報はこのファイルの外部の Secret Manager に保存することをおすすめします。

起動時に、インスタンスが空で、ユーザーがいない場合は、これらの認証情報を使用して Looker 管理 API ユーザーを作成し、ディスクから api-provision.yml ファイルを削除します。

その後 30 分間は、これらの認証情報を使用して追加のプロビジョニングを行うことができます。その後、認証情報が内部データベースから削除され、使用できなくなります。これらの初期認証情報を削除することで、アプリケーションへの長期的なバックドアの作成を回避し、意図されたユースケースを厳密にプロビジョニングできます。