La plupart des opérations que vous effectuez dans Cloud Storage doivent être authentifiées.
Les seules exceptions concernent les opérations réalisées sur des objets qui autorisent les accès anonymes. Les objets sont accessibles de manière anonyme si le groupe allUsers
dispose de l'autorisation READ
. Le groupe allUsers
comprend tous les internautes.
OAuth 2.0
Authentification
Cloud Storage utilise le protocole OAuth 2.0 pour l'authentification et l'autorisation de l'API. L'authentification est le processus permettant de déterminer l'identité d'un client. Les détails de l'authentification varient selon la manière dont vous accédez à Cloud Storage, mais se divisent en deux types généraux :
Un flux centré sur le serveur permet à une application de détenir directement les identifiants d'un compte de service pour effectuer l'authentification. Utilisez ce flux si votre application utilise ses propres données plutôt que des données utilisateur. Vous pouvez utiliser les comptes de service par défaut des projets Google Cloud ou vous pouvez en créer d'autres.
Un flux centré sur l'utilisateur permet à une application d'obtenir les identifiants d'un utilisateur final. L'utilisateur se connecte pour procéder à l'authentification. Utilisez ce flux si votre application doit accéder aux données utilisateur. Pour connaître les scénarios dans lesquels un flux centré sur l'utilisateur est approprié, consultez la section Identifiants de compte utilisateur plus loin sur cette page.
N'oubliez pas que vous pouvez combiner les deux types d'authentification dans une application. Pour plus d'informations générales sur l'authentification, consultez le guide d'authentification Google Cloud.
Champs d'application
L'autorisation est le processus permettant de déterminer les autorisations dont dispose une identité authentifiée sur un ensemble de ressources spécifiées. OAuth 2.0 détermine si une identité authentifiée est autorisée à l'aide de champs d'application. Les applications utilisent des identifiants (obtenus à partir d'un flux d'authentification centré sur l'utilisateur ou sur le serveur) avec un ou plusieurs champs d'application pour demander un jeton d'accès à un serveur d'autorisation Google afin d'accéder aux ressources protégées. Par exemple, l'application A dotée d'un jeton d'accès ayant le champ d'application read-only
ne peut que lire des données, tandis que l'application B dotée d'un jeton d'accès ayant le champ d'application read-write
peut lire et modifier des données. Aucune des deux applications ne peut lire ni modifier les listes de contrôle d'accès sur les objets et les buckets. Seule une application ayant le champ d'application full-control
peut le faire.
Type | Description | URL du champ d'application |
---|---|---|
read-only |
Octroie un accès ne permettant que de lire les données, y compris de répertorier les buckets. | https://www.googleapis.com/auth/devstorage.read_only |
read-write |
Octroie un accès permettant de lire et de modifier les données, mais pas les métadonnées telles que les stratégies IAM. | https://www.googleapis.com/auth/devstorage.read_write |
full-control |
Permet d'exercer un contrôle total sur les données, y compris de modifier les stratégies IAM. | https://www.googleapis.com/auth/devstorage.full_control |
cloud-platform.read-only |
Permet d'afficher les données dans les services Google Cloud. Pour Cloud Storage, ce champ d'application est identique à devstorage.read-only .
|
https://www.googleapis.com/auth/cloud-platform.read-only |
cloud-platform |
Permet d'afficher et de gérer les données dans tous les services Google Cloud. Pour Cloud Storage, ce champ d'application est identique à devstorage.full-control . |
https://www.googleapis.com/auth/cloud-platform |
Authentification gsutil
Lorsque gsutil est installé à partir du SDK Cloud, vous devez vous authentifier avec des identifiants de compte de service.
Utilisez un compte de service existant ou créez-en un, puis téléchargez la clé privée associée. Vous ne pouvez télécharger les données de clé privée d'une clé de compte de service qu'au moment où vous la créez.
Exécutez
gcloud auth activate-service-account
pour vous authentifier à l'aide du compte de service :gcloud auth activate-service-account --key-file KEY_FILE
Où
KEY_FILE
est le nom du fichier contenant les identifiants de votre compte de service.
gcloud auth
utilise le champ d'application cloud-platform
lors de l'obtention d'un jeton d'accès.
Si vous avez installé gsutil indépendamment du SDK Cloud, consultez la page d'installation de gsutil pour obtenir des informations sur la procédure d'authentification.
Authentification des bibliothèques clientes
Les bibliothèques clientes peuvent utiliser les identifiants par défaut de l'application pour s'authentifier facilement auprès des API Google et envoyer des requêtes à ces API. Ces identifiants vous permettent de tester votre application localement et de la déployer sans modifier le code sous-jacent. Pour obtenir davantage d'informations, y compris des exemples de code, consultez le Guide d'authentification Google Cloud Platform.
Google Cloud
Si vous exécutez votre application sur App Engine ou Compute Engine, l'environnement fournit déjà les informations d'authentification d'un compte de service. Aucune autre configuration n'est donc requise. Pour Compute Engine, le champ d'application du compte de service dépend de la manière dont vous avez créé l'instance. Consultez la section Définir le champ d'application de l'accès au compte de service pour les instances. Pour App Engine, le champ d'application
cloud-platform
est employé.Autres environnements
Pour initialiser votre environnement de développement ou de production local, créez un compte de service Google Cloud, téléchargez sa clé, puis définissez la variable d'environnement
GOOGLE_APPLICATION_CREDENTIALS
pour qu'elle utilise la clé. Pour obtenir des informations détaillées, consultez la section Configurer l'authentification qui concerne les bibliothèques clientes Cloud Storage. Au lieu de définir une variable d'environnement, vous pouvez utiliser la clé du compte de service directement dans le code.
Authentification de l'API
Pour envoyer des requêtes à l'aide d'OAuth 2.0 à l'API XML ou l'API JSON Cloud Storage, incluez le jeton d'accès de votre application dans l'en-tête Authorization
de chaque requête qui nécessite une authentification. Vous pouvez générer un jeton d'accès depuis la page OAuth 2.0 Playground.
Authorization: Bearer OAUTH2_TOKEN
Vous trouverez ci-dessous un exemple de requête qui répertorie les objets d'un bucket.
API JSON
Utilisez la méthode list de la ressource Objects.
GET /storage/v1/b/example-bucket/o HTTP/1.1 Host: www.googleapis.com Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg
Pour autoriser des requêtes à partir de la ligne de commande ou pour les tester, vous pouvez exécuter la commande curl avec la syntaxe suivante :
curl -H "Authorization: Bearer OAUTH2_TOKEN""https://storage.googleapis.com/storage/v1/b/BUCKET_NAME/o"
Pour les tests en local, vous pouvez exécuter la commande gcloud auth application-default print-access-token
pour générer un jeton.
API XML
Utilisez une requête Répertorier les objets.
GET / HTTP/1.1 Host: example-bucket.storage.googleapis.com Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg
Pour autoriser des requêtes à partir de la ligne de commande ou pour les tester, vous pouvez exécuter la commande curl avec la syntaxe suivante :
curl -H "Authorization: Bearer OAUTH2_TOKEN""https://BUCKET_NAME.storage.googleapis.com"
Pour les tests en local, vous pouvez exécuter la commande gcloud auth application-default print-access-token
pour générer un jeton.
En raison de la complexité de la gestion et de l'actualisation des jetons d'accès, et du risque de sécurité lié à l'interaction directe avec des applications de chiffrement, nous vous encourageons vivement à utiliser une bibliothèque cliente validée.
Si vous recherchez des clés HMAC à utiliser avec l'API XML pour obtenir un accès en interopérabilité avec Amazon S3, consultez la page Gérer des clés HMAC pour les comptes de service.
Identifiants de compte utilisateur
Utilisez les identifiants de compte utilisateur pour l'authentification lorsque votre application doit accéder aux données au nom d'un utilisateur. Sinon, utilisez des identifiants de compte de service. Voici des exemples de scénarios dans lesquels les identifiants de compte utilisateur peuvent être employés :
- Applications de serveur Web
- Applications de bureau et applications installées
- Applications mobiles
- Code JavaScript côté client
- Applications sur des périphériques à saisie limitée
Pour plus d'informations sur ces scénarios, consultez la section Scénarios OAuth 2.0.
Si vous concevez une application de sorte qu'elle accepte plusieurs options d'authentification pour les utilisateurs finaux, utilisez l'authentification Firebase, qui accepte l'authentification par e-mail et par mot de passe, ainsi que la connexion fédérée via des fournisseurs d'identité tels que Google, Facebook, Twitter et GitHub.
Lorsqu'une application se voit attribuer un jeton d'accès dans un flux d'authentification centré sur l'utilisateur par un utilisateur final, ce jeton d'accès ne dispose que des autorisations disponibles pour l'utilisateur qui octroie le jeton. Par exemple, si jane@gmail.com dispose d'un accès read-only
à example-bucket
, une application à laquelle Jane a accordé un accès read-write
ne peut pas écrire dans example-bucket
en son nom.
Étape suivante
- Apprenez-en plus sur les téléchargements via un navigateur utilisant l'authentification par cookie.
- Découvrez comment les comptes de service sont utilisés de manière générale dans Google Cloud et de manière spécifique dans Cloud Storage.
- Apprenez-en plus sur les clés API, qui peuvent être utilisées pour identifier une application.