6

Qual è il modo migliore per distribuire le credenziali dell'account del servizio Google all'interno di un contenitore Docker CentOS personalizzato per l'esecuzione sul motore di contenitore di Google o sul suo "container-vm"? Questo comportamento si verifica automaticamente nel contenitore google/cloud-sdk, che esegue debian e include cose che non sto utilizzando come app-eng/java/php. Idealmente, sto tentando di accedere a risorse non pubbliche all'interno del mio progetto, ad es. Oggetti bucket di Google Cloud Storage, senza effettuare il log in e autorizzare ogni volta che viene lanciato un numero elevato di questi contenitori.Autenticazione dell'account di servizio GCE consigliata all'interno del contenitore Docker?

Ad esempio, su un contenitore di base CentOS in esecuzione su GCE con codice personalizzato e gcloud/gsutil installato, quando si esegue:

docker run --rm -ti custom-container gsutil ls 

Viene richiesto di eseguire "config gsutil" per ottenere l'autorizzazione, che ho aspettarsi.

Tuttavia, tirando giù il contenitore google/cloud-sdk sullo stesso GCE ed eseguendo lo stesso comando, sembra che l'ereditarietà delle credenziali sia configurata in modo intelligente (forse dal contenitore dell'host, le credenziali di vm?). Questo sembra ignorare l'esecuzione di "gsutil config" quando si esegue il contenitore su GCE per accedere alle risorse private.

Sto cercando di replicare tale comportamento in un contenitore Centos di dimensioni minime per l'implementazione di massa.

+0

La tua domanda su come eseguire facilmente l'autenticazione da GCE a GCS o su come disporre di un contenitore di SDK gcloud minimo o qualcos'altro? Perché pensi che sia buono per lo sviluppo ma non per la produzione? Quali problemi stai incontrando quando hai molti di quei contenitori? Inoltre, considera la suddivisione della seconda parte del post in una domanda separata. –

+0

Modificato sopra per tentato chiarimento. – GNN

risposta

2

Follow-up.

Ho terminato di utilizzare le directory /.config & /.gce e un set molto minimale di componenti GCE SDK (nessun JDK/PHP/ecc.). Il wheezy-cloudtools Dockerfile si è dimostrato il miglior esempio che ho trovato.

4

Aggiornamento: a partire dal 15 dicembre 2016, la possibilità di aggiornare gli ambiti di una macchina virtuale esistente è ora in beta; vedi this SO answer per maggiori dettagli.


Vecchia risposta: Un approccio è quello di creare la VM con appropriate scopes (ad esempio, Google Cloud Storage di sola lettura o di lettura e scrittura) e quindi tutti i processi sul VM, compresi contenitori, avranno accesso a credenziali che possono utilizzare tramite OAuth 2.0; vedere i documenti per Google Cloud Storage e Google Compute Engine.

Si noti che una volta creata una VM con una serie di ambiti, non possono essere modificati in seguito (né aggiunti né rimossi), quindi è necessario impostare il set di ambiti corretto al momento della creazione dell'istanza VM.

+0

Grazie. Questo è in realtà ciò che ho fatto, tuttavia non ha funzionato come previsto per le autorizzazioni all'interno del progetto. Userò la memoria di GS come esempio sin dalla sua base. Il motore contenitore è stato creato con gli --scopes https://www.googleapis.com/auth/devstorage.read_write. Quindi distribuisco il contenitore di ubuntu di base e il contenitore di google/cloud-sdk. Solo il contenitore google/cloud-sdk può eseguire un "gsutil ls". Il contenitore di ubuntu che vedi "Stai tentando di eseguire un'operazione che richiede un id di progetto, con nessuno configurato" – GNN

+0

Hai usato 'gcloud config set project PROJECT' per impostare un progetto predefinito, o specificare il progetto esplicitamente tramite' gsutil ls - p PROGETTO gs: // bucket'? –