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, dove 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 Looker è nuova e non è ancora stata configurata, verrà eseguito il provisioning con la chiave di 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. Questo è utile per aggiornare un'istanza di staging di Looker con una copia aggiornata del database interno di un'istanza di produzione, mantenendo al contempo una chiave di licenza e un URL separati per il server di staging.
Eseguire automaticamente il provisioning 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 cliente deve contenere 20 caratteri.
- Il segreto client 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 seguente codice 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 utilizzando il comando openssl:
openssl rand -hex 10
Il numero alla fine del comando openssl è il numero di byte nella stringa, quindi utilizza 10 per l'ID cliente e 12 per il client secret.
Esegui il provisioning dell'utente API
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 API di amministrazione di Looker con queste credenziali e rimuove il file api-provision.yml dal disco.
Hai 30 minuti di tempo per utilizzare queste credenziali per eseguire un provisioning aggiuntivo prima che vengano rimosse dal database interno e non siano più utilizzabili. La rimozione di queste credenziali iniziali evita di creare una backdoor permanente nell'applicazione e limita il caso d'uso previsto esclusivamente al provisioning.