Facoltativamente, all'avvio di una nuova istanza di Looker ospitata dal cliente, puoi eseguire automaticamente il provisioning dell'istanza con una codice licenza, un URL host e un account utente iniziale.
Provisioning automatico di una nuova istanza con un utente email
All'avvio iniziale, Looker cerca un file denominato provision.yml
nella directory looker
in cui si trova il file JAR. Il formato di questo file è il seguente:
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"
Se l'istanza di Looker è nuova e non è stata ancora configurata, il provisioning verrà eseguito con la codice licenza specificata e un account utente con le informazioni fornite.
Se è già stato eseguito il provisioning di Looker, i valori della codice licenza e dell'URL dell'host sostituiranno qualsiasi codice licenza e URL dell'host attualmente impostati. Le informazioni utente verranno ignorate. Ciò è utile per aggiornare un'istanza temporanea di Looker con una copia aggiornata del database interno di un'istanza di produzione, mantenendo al contempo una codice licenza e un URL separati per il server di gestione temporanea.
Provisioning automatico di una nuova istanza con un utente API
All'avvio di una nuova istanza di Looker, puoi eseguire il provisioning di un utente API iniziale in modo programmatico. Puoi eseguire il provisioning di un utente API OPPURE di un utente email, ma Looker non supporta il provisioning di un utente API e di un utente email contemporaneamente.
Generazione delle credenziali API in corso...
Per eseguire il provisioning di un utente API, genera un ID client e un client secret che Looker leggerà e salvi nel database. I requisiti per queste credenziali sono:
- L'ID client deve contenere 20 caratteri.
- Il client secret deve avere una lunghezza di 24 caratteri.
- Entrambe le stringhe devono poter essere incluse nel corpo di una richiesta
POST
, pertanto si consiglia di utilizzare solo caratteri alfanumerici.
Ad esempio, Looker utilizza il codice seguente per generare queste credenziali in modo programmatico:
require 'securerandom'
TOKEN_SYMBOLS = "bcdfghjkmnpqrstvwxyzBCDFGHJKMNPQRSTVWXYZ23456789".freeze
def generate_token(size)
Array.new(size).map { TOKEN_SYMBOLS[SecureRandom.random_number(TOKEN_SYMBOLS.size)] }.join
end
Questo codice evita caratteri ambigui per rendere le stringhe meno soggette a errori.
Puoi anche generare stringhe adatte con il comando openssl
:
openssl rand -hex 10
Il numero alla fine del comando openssl
corrisponde al numero di byte nella stringa, quindi usa 10
per l'ID client e 12
per il client secret.
Provisioning dell'utente API in corso
Per eseguire il provisioning di un utente API all'avvio, assicurati di avere un file provision.yml
che includa la codice licenza e l'URL dell'host nella directory looker
. Ad esempio:
license_key: "1234-5678-ABCD-EFGH-IJKL"
host_url: "https://looker.mycompany.com"
Crea un file denominato api-provision.yml
con le autorizzazioni 0600
nella directory looker
che include le informazioni utente dell'API. Ad esempio:
user:
first_name: "Ariel"
last_name: "Q"
client_id: "M9hZb8vRh9bSZzdPxw42"
client_secret: "NMnqBVbHqPsPzTvbZk6xZfV3"
Ti consigliamo di archiviare queste credenziali in un Secret Manager esterno a questo file, poiché questo file verrà rimosso all'avvio dopo che l'istanza di Looker avrà elaborato e creato l'utente nel database.
All'avvio, se l'istanza è vuota e non sono presenti utenti, Looker crea un utente dell'API amministrativa di Looker con queste credenziali e rimuove il file api-provision.yml
dal disco.
Hai quindi 30 minuti di tempo per utilizzare queste credenziali per eseguire ulteriori provisioning prima che vengano rimosse dal database interno e non siano più utilizzabili. La rimozione di queste credenziali iniziali evita la creazione di una backdoor di lunga durata nell'applicazione e mantiene il caso d'uso previsto esclusivamente al provisioning.