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보다 우선 적용됩니다. 사용자 정보는 무시됩니다. 스테이징 서버의 별도 라이선스 키와 URL을 유지하면서 프로덕션 인스턴스의 내부 데이터베이스로 새로운 Looker 인스턴스 인스턴스를 업데이트하는 데 유용합니다.

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 사용자를 프로비저닝하려면 라이선스 키와 호스트 URL이 포함된 provision.yml 파일이 looker 디렉터리에 있어야 합니다. 예를 들면 다음과 같습니다.

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

API 사용자 정보가 포함된 looker 디렉터리에 0600 권한이 있는 api-provision.yml 파일을 만듭니다. 예를 들면 다음과 같습니다.

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

이 파일은 Looker 인스턴스가 처리하여 데이터베이스에서 사용자를 생성하면 시작 시 삭제되므로 이 파일 외부의 보안 비밀 관리자에 저장하는 것이 좋습니다.

시작 시 인스턴스가 비어 있고 사용자가 없는 경우 Looker는 이러한 사용자 인증 정보를 사용하여 Looker 관리자 API 사용자를 만들고 디스크에서 api-provision.yml 파일을 삭제합니다.

사용자 인증 정보가 내부 데이터베이스에서 삭제되고 더 이상 사용할 수 없게 되기 전에 30분 내에 이러한 사용자 인증 정보를 사용하여 추가 프로비저닝을 해야 합니다. 이러한 초기 사용자 인증 정보를 삭제하면 애플리케이션에 수명이 긴 백도어가 생성되지 않으며, 오직 의도한 사용 사례가 프로비저닝에만 국한됩니다.