Facoltativamente, all'avvio di una nuova istanza di Looker, puoi eseguire automaticamente il provisioning dell'istanza con un 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, verrà eseguito il provisioning della codice licenza specificata e di 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 quelli impostati attualmente per la codice licenza e l'URL dell'host. Le informazioni utente verranno ignorate. Questo è utile per aggiornare un'istanza di gestione temporanea di Looker con una nuova copia del database interno di un'istanza di produzione, mantenendo comunque 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 programmatico di un utente API iniziale. Puoi eseguire il provisioning di un utente API o di un utente email, ma Looker non supporta contemporaneamente il provisioning di un utente API e un utente email.
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 salverà sul database. I requisiti per queste credenziali sono:
- L'ID client deve avere 20 caratteri.
- Il client secret deve avere una lunghezza di 24 caratteri.
- Entrambe le stringhe devono essere incluse nel corpo di una richiesta
POST, perciò è consigliabile utilizzare solo caratteri alfanumerici.
Ad esempio, Looker utilizza il seguente codice per generare le 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
Il codice riportato sopra evita caratteri ambigui rendendo le stringhe meno soggette a errori.
Puoi anche generare stringhe appropriate utilizzando il comando openssl:
openssl rand -hex 10
Il numero alla fine del comando openssl è il numero di byte nella stringa, quindi usa 10 per l'ID client e 12 per il client secret.
Provisioning dell'utente API
Per eseguire il provisioning di un utente API all'avvio, assicurati di avere un file provision.yml che includa il codice licenza e l'URL dell'host nella directory looker. Ecco alcuni esempi:
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 includa le informazioni utente dell'API. Ecco alcuni esempi:
user:
first_name: "Ariel"
last_name: "Q"
client_id: "M9hZb8vRh9bSZzdPxw42"
client_secret: "NMnqBVbHqPsPzTvbZk6xZfV3"
Ti consigliamo di archiviare queste credenziali in un gestore secret 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 amministratore di Looker con queste credenziali e rimuove il file api-provision.yml dal disco.
Avrai a disposizione 30 minuti per utilizzare queste credenziali per eseguire il provisioning aggiuntivo prima che vengano rimosse dal database interno e non siano più utilizzabili. La rimozione di queste credenziali iniziali evita di creare un backdoor di lunga durata nell'applicazione e conserva rigorosamente il caso d'uso previsto per il provisioning.