새 Looker 인스턴스 자동 프로비저닝

원하는 경우 새 Looker 고객 호스팅 인스턴스를 시작할 때 라이선스 키, 호스트 URL, 초기 사용자 계정을 사용하여 인스턴스를 자동으로 프로비저닝할 수 있습니다.

이메일 사용자로 새 인스턴스 자동 프로비저닝

처음 시작할 때 Looker는 JAR 파일이 있는 looker 디렉터리에서 provision.yml이라는 파일을 스캔합니다. 이 파일의 형식은 다음과 같습니다.

license_key: "1234-5678-ABCD-EFGH-IJKL"
host_url: "https://looker.mycompany.com"
user:
  first_name: "Ariel"
  last_name: "Q"
  email: "arielq@altostrat.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: "Ariel"
  last_name: "Q"
  client_id: "M9hZb8vRh9bSZzdPxw42"
  client_secret: "NMnqBVbHqPsPzTvbZk6xZfV3"

이 파일은 Looker 인스턴스가 데이터베이스에서 사용자를 처리하고 만들면 시작 시 삭제되므로 이 파일 외부의 Secret Manager에 이러한 사용자 인증 정보를 저장하는 것이 좋습니다.

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

그런 다음 내부 데이터베이스에서 사용자 인증 정보가 삭제되어 더 이상 사용할 수 없게 되기 전에 이러한 사용자 인증 정보를 사용하여 30분 동안 추가 프로비저닝을 수행할 수 있습니다. 이러한 초기 사용자 인증 정보를 제거하면 애플리케이션에 장기 백도어가 생성되는 것을 방지하고 의도된 사용 사례를 프로비저닝으로 엄격하게 유지합니다.