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 aux données publiques de manière anonyme. 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.

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).

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 :

Ce type d'identifiant peut être utilisé pour authentifier des requêtes au nom d'un utilisateur spécifique (sans doute l'utilisation la plus courante de gsutil). Il est créé par défaut lorsque vous exécutez gcloud init. Ce type d'identifiant n'est pas compatible avec les versions autonomes de gsutil. 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 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 gcloud init, 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 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 envisagez d'exécuter gsutil à partir d'une tâche Cron nocturne pour importer ou télécharger des données, l'utilisation d'un compte de service signifie que la tâche Cron ne dépend pas des identifiants d'un employé de votre entreprise. Cet identifiant est configuré lorsque vous exécutez gcloud auth activate-service-account (ou gsutil config -e lorsque vous utilisez des versions autonomes de gsutil).

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 gcloud auth activate-service-account ou gsutil config -e, consultez https://cloud.google.com/storage/docs/authentication#generating-a-private-key

Pour en savoir plus sur les comptes de service OAuth2, consultez la page https://developers.google.com/accounts/docs/OAuth2ServiceAccount.

Pour en savoir plus sur les rôles associés aux comptes, consultez la page https://developers.google.com/console/help/#DifferentRoles.

Compte de service interne Compute Engine :

Il s'agit du type de compte de service utilisé pour les comptes hébergés par App Engine ou Compute Engine. Ces identifiants sont créés automatiquement sur 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 l'utilisation des identifiants de compte de service pour l'authentification des charges de travail sur Compute Engine, consultez la page https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances.

Pour en savoir plus sur les comptes de service App Engine, consultez la page 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 gsutil -i, gsutil config -e et en modifiant le fichier de configuration boto, ou gcloud config set auth/impersonate_service_account [service_account_email_address].

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 https://cloud.google.com/iam/docs/creating-short-lived-service-account-credentials.

Identifiants de compte externes (fédération d'identité de charge de travail) :

Grâce à la fédération d'identité de charge de travail, vous pouvez accéder aux ressources Google Cloud depuis Amazon Web Services (AWS), Microsoft Azure ou tout fournisseur d'identité compatible avec OpenID Connect (OIDC) ou SAML 2.0.

Pour en savoir plus, consultez la page https://cloud.google.com/iam/docs/using-workload-identity-federation.