Types d'identifiants prenant en charge divers cas d'utilisation

Présentation

gsutil est actuellement compatible avec plusieurs types d'identifiants et d'authentifications. Il permet également d'accéder anonymement aux données publiques. Pour en savoir plus sur l'accès anonyme, consultez la page sur gsutil help anon. Ces identifiants sont décrits plus en détail ci-dessous. Vous trouverez également des informations sur la configuration et l'utilisation des identifiants à l'aide du SDK Cloud ou des installations autonomes de gsutil.

Configurer et utiliser des identifiants à l'aide de la distribution de gsutil du SDK Cloud

Lorsque vous installez ou utilisez gsutil via le SDK Cloud ("gcloud"), les identifiants sont stockés par le SDK Cloud dans un fichier non modifiable par l'utilisateur situé sous ~/.config/gcloud (toute manipulation des identifiants doit être effectuée à l'aide de la commande "gcloud auth"). Si vous devez configurer plusieurs identifiants (un pour un compte utilisateur individuel et un autre pour un compte de service, par exemple), la commande "gcloud auth" gère les identifiants à votre place. Vous pouvez également basculer d'un identifiant à l'autre à l'aide de cette commande. Pour en savoir plus, consultez la page https://cloud.google.com/sdk/gcloud/reference/auth.

Les identifiants peuvent être utilisés une fois configurés à l'aide de la commande "gcloud auth", que l'utilisateur possède ou non des fichiers de configuration boto (situés sous ~/.boto, à moins qu'un autre chemin soit spécifié dans la variable d'environnement BOTO_CONFIG). Toutefois, gsutil recherche toujours les identifiants dans le fichier de configuration boto si un type d'identifiant autre que Cloud Storage est nécessaire et ne se trouve pas dans le stockage des identifiants gcloud (par exemple, des identifiants HMAC pour un compte S3).

Configurer et utiliser des identifiants à l'aide de la distribution autonome de gsutil

Si vous avez installé une distribution autonome de gsutil (téléchargée depuis https://pub.storage.googleapis.com/gsutil.tar.gz, https://pub.storage.googleapis.com/gsutil.zip ou PyPi), les identifiants sont configurés à l'aide de la commande "gsutil config" et stockés dans le fichier de configuration boto modifiable par l'utilisateur (situé sous ~/.boto, à moins qu'un autre chemin soit spécifié dans la variable d'environnement BOTO_CONFIG). Dans ce cas, si vous souhaitez configurer plusieurs identifiants (un pour un compte utilisateur individuel et un autre pour un compte de service, par exemple), exécutez la commande "gsutil config" une fois pour chaque identifiant et enregistrez chacun des fichiers de configuration boto générés (par exemple, renommez-en un ~/.boto_user_account et l'autre ~/.boto_service_account). Vous pouvez basculer d'un identifiant à l'autre à l'aide de la variable d'environnement BOTO_CONFIG (en exécutant "BOTO_CONFIG=~/.boto_user_account gsutil ls" entre autres).

Notez que lorsque vous utilisez la version autonome de gsutil avec l'API JSON, vous pouvez configurer l'un des types d'identifiants Cloud Storage suivants dans un seul fichier de configuration boto : compte utilisateur OAuth2 ou compte de service OAuth2. Vous pouvez également disposer d'identifiants HMAC S3 (nécessaires pour utiliser les URL s3://) et d'identifiants de compte de service interne Google Compute Engine. Les identifiants du compte de service interne Google Compute Engine ne sont utilisés que si les identifiants OAuth2 ne sont pas présents.

Types d'identifiants compatibles

gsutil accepte plusieurs types d'identifiants. Le sous-ensemble spécifique dépend de la distribution de gsutil que vous utilisez. Pour en savoir plus, consultez les sections ci-dessus.

Compte utilisateur OAuth2 :
Il s'agit du type d'identifiant privilégié pour authentifier les requêtes au nom d'un utilisateur spécifique (sans doute l'utilisation la plus courante de gsutil). Cet identifiant par défaut est créé lorsque vous exécutez la commande "gsutil config" (ou "gcloud init" pour les installations SDK Cloud). Pour en savoir plus sur l'authentification OAuth2, consultez la page https://developers.google.com/accounts/docs/OAuth2#scenarios
.
HMAC :

Ce type d'identifiant peut être utilisé par les programmes mis en œuvre à l'aide de l'authentification HMAC, un mécanisme d'authentification accepté par certains fournisseurs de services de stockage dans le cloud. Cet identifiant peut également être utilisé de manière interactive lors du transfert de données depuis ou vers des fournisseurs de services qui acceptent les identifiants HMAC. Il est créé lorsque vous exécutez la commande "gsutil config -a".

Notez qu'il est possible de configurer des identifiants HMAC pour Cloud Storage et un autre fournisseur de services, ou de configurer des identifiants de compte utilisateur OAuth2 pour Cloud Storage et des identifiants HMAC pour un autre fournisseur de services. Pour ce faire, après avoir exécuté la commande "gsutil config" (ou "gcloud init" pour les installations SDK Cloud), vous pouvez modifier le fichier de configuration ~/.boto généré et rechercher des commentaires pour déterminer où ajouter d'autres identifiants.

Pour en savoir plus sur l'authentification HMAC, consultez la page suivante :
https://developers.google.com/storage/docs/reference/v1/getting-startedv1#keys
Compte de service OAuth2 :

Il s'agit du type d'identifiant à privilégier en cas d'authentification au nom d'un service ou d'une application (et non d'un utilisateur). Par exemple, si vous exécutez gsutil à partir d'une tâche Cron nocturne pour importer ou télécharger des données, l'utilisation d'un compte de service permet à la tâche Cron de ne pas dépendre des identifiants d'un employé de votre entreprise. Cet identifiant est configuré lorsque vous exécutez la commande "gsutil config -e". Pour configurer les identifiants du compte de service lors de l'installation à l'aide du SDK Cloud, exécutez la commande "gcloud auth activate-service-account".

Il est important de noter qu'un compte de service est considéré comme un éditeur par défaut pour l'accès à l'API, et non comme un propriétaire. Plus précisément, le fait que les éditeurs disposent d'un accès PROPRIÉTAIRE dans les LCA d'objets et de buckets par défaut, mais que les options de LCA standardisées leur suppriment l'accès PROPRIÉTAIRE, peut entraîner des résultats inattendus. Pour résoudre ce problème, exécutez la commande "gsutil acl ch" au lieu de "gsutil acl set <canned-ACL>" afin de modifier les autorisations sur un bucket.

Pour configurer un compte de service à utiliser avec "gsutil config -e" ou "gcloud auth enable-service-account", consultez la page suivante :

Pour en savoir plus sur les comptes de service OAuth2, consultez la page suivante :
https://developers.google.com/accounts/docs/OAuth2ServiceAccount
Pour en savoir plus sur les rôles associés aux comptes, consultez la page suivante :
https://developers.google.com/console/help/#DifferentRoles
Compte de service interne Google Compute Engine :

Il s'agit du type de compte de service utilisé pour les comptes hébergés par App Engine ou Google Compute Engine. Ces identifiants sont créés automatiquement sur Google Compute Engine lorsque vous exécutez la commande "gcloud compute instances create". Vous pouvez les contrôler à l'aide de l'option --scopes.

Pour en savoir plus sur les comptes de service Google Compute Engine, consultez la page suivante :
https://developers.google.com/compute/docs/authentication
Pour en savoir plus sur les comptes de service App Engine, consultez la page suivante :
https://developers.google.com/appengine/docs/python/appidentity/overview
Usurper l'identité d'un compte de service :

Il s'avère utile d'usurper l'identité d'un compte de service lorsque vous devez accorder un accès à court terme à des ressources spécifiques. Par exemple, si vous disposez d'un bucket de données sensibles (généralement en lecture seule) et que vous souhaitez accorder temporairement un accès en écriture via un compte de service approuvé.

Vous pouvez spécifier le compte de service dont usurper l'identité en exécutant les commandes "gsutil -i" et "gsutil config", et en modifiant le fichier de configuration boto ou la commande "gcloud config set auth/impersonate_service_account".

Pour que vous usurpiez l'identité d'un compte de service, vos identifiants d'origine doivent disposer du rôle roles/iam.serviceAccountTokenCreator sur le compte de service cible. Pour en savoir plus, consultez la page suivante :