web-dev-qa-db-fra.com

Accéder aux informations d'identification du compte de service Google Cloud sur Container OS dans Docker Container

En utilisant Container Optimized OS (COS) sur Google Cloud Compute, quelle est la meilleure façon d'accéder aux informations d'identification du compte de service par défaut pour le projet VM à partir d'un conteneur Docker ?

$ gcloud compute instances create test-instance \
  --image=cos-stable --image-project=cos-cloud

$ ssh (ip of the above)
# gcloud ...
Command not found

# docker run -ti google/cloud-sdk:Alpine /bin/sh
# gcloud auth activate-service-account
... --key-file: Must be specified.

Si les informations d'identification étaient sur la machine virtuelle, Docker pourrait simplement les monter. Habituellement, les informations d'identification seront dans .config/gcloud/, et faites-le avec docker run -v ~/.config/gcloud:~/.config/gcloud image. Il n'est pas évident si et où ces informations d'identification sont disponibles dans Container OS, d'autant plus qu'il manque gcloud.

A défaut des informations d'identification se trouvant sur le VM et montable, les options semblent inclure:

  1. Mettez les informations d'identification dans la variable de métadonnées/environnement de conteneur;
  2. Créer un .json fichier d'informations d'identification pour le compte de service, puis
    1. téléchargez-le sur la machine virtuelle, puis montez-le; ou
    2. ajouter le .json au conteneur;
  3. Exécutez un conteneur Docker (par exemple cloud-sdk-docker ) qui obtient les informations d'identification et les partage avec les hôtes via par exemple une partition de montage partagée. Idéalement, ce serait avec gcloud auth activate-service-account

Existe-t-il un moyen canonique ou conforme aux meilleures pratiques de fournir à un conteneur Docker les informations d'identification du compte de service du projet de la machine virtuelle?

Google Cloud dispose déjà d'un modèle de politique de sécurité, le modèle souhaité: a VM à l'intérieur d'un projet doit avoir l'accès fourni par le compte de service. Pour éviter la complexité et la possibilité de mauvaise configuration ou d'incident, le la bonne solution emploierait ce modèle de sécurité existant, c'est-à-dire n'impliquant pas la création, le téléchargement, la distribution et la maintenance des fichiers d'informations d'identification.

Il semble que ce soit un problème de routine qui devrait être résolu avec COS, Docker et Kubernetes, donc je suppose que j'ai raté quelque chose de simple - mais la solution ne m'a pas été révélée par la documentation.

[~ # ~] modifier [~ # ~] - Notant l'API set-service-account - cette question pourrait être réduit à "Comment utilisez-vous l'API set-service-account avec Container OS?" Si ce n'est pas possible (parce que Container OS n'a pas gcloud et gsutil), je pense que cela doit être noté afin que VM les utilisateurs puissent planifier en conséquence.

[~ # ~] modifier [~ # ~] Pour les prochains à traverser ceci:

Pour reproduire le problème, j'ai utilisé:

[local] $ ssh test-instance-ip
[test-instance] $ docker run -it gcr.io/google-appengine/python /bin/bash
[test-instance] $ pip install --upgrade google-cloud-datastore
[test-instance] $ python

>>> from google.cloud import datastore
>>> datastore_client = datastore.Client()
>>> q = datastore.query.Query(datastore_client, kind='MODEL-KIND')
>>> list(q.fetch())
[... results]

Le problème était en effet les étendues définies dans l'API pour l'instance VM, et en particulier l'API datastore a été désactivée pour le compte par défaut (sous l'en-tête Étendues d'accès à l'API Cloud pour la machine virtuelle). On peut trouver les portées et la ligne datastore nécessaire comme suit:

> gcloud compute instances describe test-instance
...
serviceAccounts:
- email: *****[email protected]
  scopes:
  - https://www.googleapis.com/auth/datastore
  ...
...

Notez que le compte de service lui-même avait l'autorisation de la banque de données (de sorte que la banque de données était accessible avec une clé d'identification json pour la clé de service, généralement). Les autorisations du compte de service étaient limitées par les étendues de la machine virtuelle.

google-cloud-platformgoogle-compute-enginegoogle-container-registrygoogle-iamgoogle-container-os
14
Brian M. Hunt

La manière habituelle de s'authentifier serait celle apparaissant sur Readme de Google Cloud SDK Docker .

À partir de l'instance COS, exécutez cette fois:

docker run -ti --name gcloud-config google/cloud-sdk gcloud auth login

Cela stockera vos informations d'identification dans le gcloud-config volume du conteneur.

Ce volume ne doit être monté qu'avec des conteneurs auxquels vous souhaitez avoir accès à vos informations d'identification, qui ne seront probablement pas des éléments qui ne sont pas cloud-sdk

docker run --rm -ti --volumes-from gcloud-config google/cloud-sdk:Alpine gcloud compute instances create test-docker --project [PROJECT]  


Created [https://www.googleapis.com/compute/v1/projects/project/zones/us-east1-b/instances/test-docker].
NAME         ZONE        MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP      STATUS
test-docker  us-east1-b  n1-standard-1               10.142.0.8   X.X.X.X  RUNNING

Les comptes de service sont généralement destinés à utiliser leur propre ensemble d'informations d'identification qu'ils doivent obtenir quelque part, être un fichier de clé et une variable d'environnement ou un jeton:

gcloud auth activate-service-account

Si vous souhaitez que gcloud (et d'autres outils du SDK Cloud) utilisent les informations d'identification du compte de service pour effectuer des demandes, utilisez cette commande pour importer ces informations d'identification à partir d'un fichier qui contient une clé d'autorisation privée et activez-les pour les utiliser dans gcloud. Cette commande remplit la même fonction que la connexion d'authentification gcloud, mais pour utiliser un compte de service plutôt que vos informations d'identification d'utilisateur Google.

En outre, la meilleure pratique consiste à créer différents comptes de service pour différentes instances, pas à obtenir la clé du compte de service par défaut et à l'utiliser:

En général, Google recommande que chaque instance qui a besoin d'appeler une API Google s'exécute en tant que compte de service avec les autorisations minimales nécessaires pour que cette instance fasse son travail. En pratique, cela signifie que vous devez configurer les comptes de service pour vos instances avec le processus suivant:

1 - Créez un nouveau compte de service plutôt que d'utiliser le compte de service par défaut de Compute Engine.
2 - Accordez des rôles IAM à ce compte de service uniquement pour les ressources dont il a besoin.
3 - Configurez l'instance pour qu'elle s'exécute en tant que compte de service.
4 - Accordez à l'instance la portée https://www.googleapis.com/auth/cloud-platform .
5 - Évitez d'accorder plus d'accès que nécessaire et vérifiez régulièrement les autorisations de votre compte de service pour vous assurer qu'elles sont à jour.

[~ # ~] mise à jour [~ # ~]

Je ne suis pas sûr que set-service-account fasse ce dont vous avez besoin/voulez. Avec lui, vous pouvez modifier le compte de service utilisé par une instance (l'instance doit cependant être arrêtée, vous ne pouvez donc pas l'utiliser pour que le compte de service ne subisse pas la modification de l'instance). Cependant, vous pouvez l'utiliser normalement pour d'autres instances, voir:

jordim@cos ~ $ docker run --rm -ti --volumes-from gcloud-config google/cloud-sdk:Alpine gcloud compute instances set-service-account instance-1 --service-account [email protected]
Did you mean zone [us-east1-b] for instance: [instance-1] (Y/n)?  

Updated [https://www.googleapis.com/compute/v1/projects/XX/zones/us-east1-b/instances/instance-1].
7
Jordi Miralles