6

Wie können Sie die Anmeldeinformationen für das Google-Dienstkonto am besten in einem benutzerdefinierten CentOS Docker-Container bereitstellen, um auf der Google Container Engine oder dem Container-vm ausgeführt zu werden? Dieses Verhalten tritt automatisch auf dem Container google/cloud-sdk auf, der debian ausführt und Dinge enthält, die ich nicht verwende, z. B. app-eng/java/php. Idealerweise versuche ich auf nicht öffentliche Ressourcen in meinem Projekt zuzugreifen, z. B. auf Google Cloud Storage-Bucket-Objekte, ohne sich jedes Mal anzumelden und zu autorisieren, wenn eine große Anzahl dieser Container gestartet wird.Empfohlene Authentifizierung des GCE-Dienstkontos im Docker-Container?

Zum Beispiel auf einer Basis Centos Container auf GCE mit benutzerdefinierten Code ausgeführt wird und gcloud/gsutil installiert, wenn Sie laufen:

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

Sie aufgefordert werden, „gsutil config“ laufen Genehmigung zu erlangen, die ich erwarten von.

Wenn Sie jedoch den google/cloud-sdk Container auf dasselbe GCE ziehen und den gleichen Befehl ausführen, scheint die Vererbung der Anmeldeinformationen (möglicherweise aus den Anmeldedaten des Host-Containers - vm) geschickt konfiguriert zu sein. Dies scheint die Ausführung von "gsutil config" zu umgehen, wenn der Container auf GCE ausgeführt wird, um auf private Ressourcen zuzugreifen.

Ich bin auf der Suche, um dieses Verhalten in einem minimalen Build Centos Container für die Massenbereitstellung zu replizieren.

+0

Sie haben Fragen zur einfachen Authentifizierung von GCE zu GCS oder zu einem minimalen gcloud SDK-Container oder etwas anderem? Warum denken Sie, dass es gut für die Entwicklung ist, aber nicht für die Produktion? Auf welche Probleme stoßen Sie, wenn Sie viele dieser Container haben? Erwägen Sie auch, den zweiten Teil des Posts in eine separate Frage aufzuteilen. –

+0

Oben für die Klärung bearbeitet. – GNN

Antwort

2

Follow-up.

Ich beendete die Verwendung der /.config & /.GCE-Verzeichnisse und eine sehr minimale Reihe von GCE SDK-Komponenten (kein JDK/PHP/etc). Die wheezy-cloudtools Dockerfile erwies sich als das beste Beispiel, das ich finden konnte.

4

Update: ab dem 15. Dezember 2016 ist die Fähigkeit, die Bereiche einer vorhandenen VM zu aktualisieren, jetzt in der Betaversion; Weitere Informationen finden Sie unter this SO answer.


Alte Antwort: Ein Ansatz ist es, die VM mit appropriate scopes (zB Google Cloud Storage read-only oder read-write) und dann alle Prozesse auf der VM, einschließlich Container zu erstellen, haben Zugang zu Anmeldeinformationen, die sie über OAuth 2.0 verwenden können; siehe Dokumente für Google Cloud Storage und Google Compute Engine.

Beachten Sie, dass, sobald eine VM mit einigen Bereichen erstellt wurde, diese später nicht geändert werden können (weder hinzugefügt noch entfernt). Daher müssen Sie zum Zeitpunkt der Erstellung der VM-Instanz die richtigen Bereiche festlegen.

+0

Danke. Das ist tatsächlich, was ich getan habe, aber es hat nicht wie erwartet von Berechtigungen innerhalb des Projekts gearbeitet. Ich werde GS-Speicher als ein Beispiel seit seiner Grund verwenden. Die Container-Engine wurde mit den --scopes https://www.googleapis.com/auth/devstorage.read_write erstellt. Dann stelle ich den Basis-Ubuntu-Container und den Google/Cloud-SDK-Container bereit. Nur der Google/Cloud-SDK-Container kann ein "gsutil ls" ausführen. Der Ubuntu-Container, den Sie sehen "Sie versuchen, eine Operation auszuführen, die eine Projekt-ID erfordert und keine konfiguriert ist" – GNN

+0

Haben Sie 'gcloud config set project PROJECT' verwendet, um ein Standardprojekt festzulegen oder das Projekt explizit über' gsutil ls - p PROJEKT gs: // Eimer? –