Facoltativamente, all'avvio di una nuova istanza di Looker, puoi eseguire il provisioning automatico dell'istanza con un codice licenza, l'URL host e l'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 risiede 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: "Katie"
last_name: "Woolsey"
email: "kwoolsey@benaventi.com"
password: "password123"
Se l'istanza di Looker è nuova e non è stata ancora configurata, verrà eseguito il provisioning con il codice licenza specificato e con un account utente con le informazioni fornite.
Se è già stato eseguito il provisioning di Looker, i valori della chiave e dell'URL dell'host hanno la precedenza sulla chiave e sull'URL dell'host attualmente impostati. Le informazioni dell'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 e mantenere un codice licenza e un URL separati per il server temporaneo.
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 il provisioning simultaneo di un utente API e di 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à nel database. I requisiti per queste credenziali sono:
- L'ID client deve contenere 20 caratteri.
- Il client secret deve contenere 24 caratteri.
- Entrambe le stringhe devono essere incluse nel corpo di una richiesta
POST, pertanto è consigliabile utilizzare solo caratteri alfanumerici.
Ad esempio, Looker utilizza il seguente codice per generare a livello di programmazione queste credenziali:
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 per rendere 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 dell'API
Per eseguire il provisioning di un utente dell'API all'avvio, assicurati di avere un file provision.yml che includa il 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 includa le informazioni utente dell'API. Ad esempio:
user:
first_name: "Katie"
last_name: "Woolsey"
client_id: "M9hZb8vRh9bSZzdPxw42"
client_secret: "NMnqBVbHqPsPzTvbZk6xZfV3"
Ti consigliamo di archiviare queste credenziali in un Secret Manager al di fuori di questo file, poiché il file verrà rimosso all'avvio una volta che l'istanza di Looker ha elaborato e creato l'utente nel database.
All'avvio, se l'istanza è vuota e non sono presenti utenti, Looker crea un utente API Admin di Looker con queste credenziali e rimuove il file api-provision.yml dal disco.
Avrai 30 minuti di tempo per utilizzare queste credenziali per eseguire il provisioning aggiuntivo prima che le credenziali vengano rimosse dal database interno e non siano più utilizzabili. La rimozione di queste credenziali iniziali evita la creazione di un backdoor di lunga durata nell'applicazione e conserva strettamente il caso d'uso previsto per il provisioning.