Migrer depuis Amazon S3 vers Cloud Storage

Cette page explique aux utilisateurs qui envoient des requêtes à l'aide d'une API comment migrer depuis Amazon Simple Storage Service (Amazon S3) vers Cloud Storage. Si vous n'utilisez pas Amazon S3 actuellement et que vous souhaitez envoyer des requêtes à l'aide de l'API Cloud Storage, consultez le document Présentation de l'API XML.

Si vous débutez sur Cloud Storage et que vous ne souhaitez pas utiliser directement l'API, vous pouvez envisager d'utiliser la console Google Cloud Platform pour définir et gérer les transferts. La console Google Cloud Platform fournit une interface graphique à Cloud  Storage qui vous permet, à l'aide d'un simple navigateur, d'accomplir la plupart de vos tâches de stockage, y compris la migration de vos données depuis Amazon S3 vers Cloud Storage.

Présentation de la migration

Si vous êtes un utilisateur d'Amazon S3, vous pouvez facilement migrer vos applications qui utilisent Amazon S3 vers Cloud Storage. Il existe deux options de migration :

Migration simple

Il s'agit du moyen le plus simple pour faire vos premiers pas avec Cloud Storage si vous venez d'Amazon S3, car il vous suffit d'apporter quelques petites modifications aux outils et aux bibliothèques que vous utilisez actuellement avec Amazon S3. Pour plus d'informations, consultez la page Migration simple.

Une migration simple vous permet de démarrer rapidement avec Cloud Storage. Toutefois, elle ne vous permet pas d'utiliser toutes les fonctionnalités de Cloud Storage. Pour profiter pleinement de Cloud Storage, effectuez une migration complète en suivant la procédure ci-dessous.

Migration complète

La migration complète depuis Amazon S3 vers Cloud Storage nécessite quelques étapes de plus que la migration simple. Mais l'avantage est que vous pouvez utiliser toutes les fonctionnalités de Cloud Storage, y compris la compatibilité avec les comptes de service, avec plusieurs projets et avec OAuth 2.0 pour l'authentification. Pour plus d'informations, consultez la section Migration complète.

Migration simple

Lors d'une migration simple depuis Amazon S3 vers Cloud Storage, vous pouvez utiliser vos outils et bibliothèques existants pour générer des requêtes REST authentifiées vers Amazon S3, afin d'envoyer également des requêtes authentifiées à Cloud Storage. Les modifications que vous devez apporter à vos outils et bibliothèques existants sont décrites dans cette section.

Pour configurer une migration simple, procédez comme suit :

  • Définissez un projet Google par défaut.
  • Obtenez une clé de développeur.
  • Effectuez les modifications suivantes dans vos outils ou bibliothèques existants :

    • Modifiez le point de terminaison de la requête pour utiliser le point de terminaison de la requête Cloud Storage.
    • Remplacez la clé secrète et la clé d'accès d'Amazon Web Services (AWS) par la clé d'accès et la clé secrète de Cloud Storage correspondantes (appelées collectivement votre clé de développeur Google).

C'est tout ! À ce stade, vous pouvez commencer à utiliser vos outils et bibliothèques existants pour envoyer des requêtes de code HMAC (Hash-based Message Authentification Code) à Cloud Storage.

Les exemples suivants montrent comment répertorier les buckets Cloud Storage à l'aide du SDK Amazon S3 :

Java

Pour plus d'informations, consultez la documentation de référence de l'API Cloud Storage en langage Java.

import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.client.builder.AwsClientBuilder;
import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.AmazonS3ClientBuilder;
import com.amazonaws.services.s3.model.Bucket;

import java.util.List;

public class ListGcsBuckets {
  public static void listGcsBuckets(String googleAccessKeyId,
      String googleAccessKeySecret) {

    // String googleAccessKeyId = "your-google-access-key-id";
    // String googleAccessKeySecret = "your-google-access-key-secret";

    // Create a BasicAWSCredentials using Cloud Storage HMAC credentials.
    BasicAWSCredentials googleCreds = new BasicAWSCredentials(googleAccessKeyId,
        googleAccessKeySecret);

    // Create a new client and do the following:
    // 1. Change the endpoint URL to use the Google Cloud Storage XML API endpoint.
    // 2. Use Cloud Storage HMAC Credentials.
    AmazonS3 interopClient = AmazonS3ClientBuilder.standard()
            .withEndpointConfiguration(
                new AwsClientBuilder.EndpointConfiguration(
                    "https://storage.googleapis.com", "auto"))
            .withCredentials(new AWSStaticCredentialsProvider(googleCreds))
            .build();

    // Call GCS to list current buckets
    List<Bucket> buckets = interopClient.listBuckets();

    // Print bucket names
    System.out.println("Buckets:");
    for (Bucket bucket : buckets) {
      System.out.println(bucket.getName());
    }

    // Explicitly clean up client resources.
    interopClient.shutdown();
  }

Python

Pour plus d'informations, consultez la documentation de référence de l'API Cloud Storage en langage Python.

import boto3

def list_gcs_buckets(google_access_key_id, google_access_key_secret):
    """Lists all GCS buckets using boto3 SDK"""
    # Create a new client and do the following:
    # 1. Change the endpoint URL to use the
    #    Google Cloud Storage XML API endpoint.
    # 2. Use Cloud Storage HMAC Credentials.
    client = boto3.client("s3", region_name="auto",
                          endpoint_url="https://storage.googleapis.com",
                          aws_access_key_id=google_access_key_id,
                          aws_secret_access_key=google_access_key_secret)

    # Call GCS to list current buckets
    response = client.list_buckets()

    # Print bucket names
    print("Buckets:")
    for bucket in response["Buckets"]:
        print(bucket["Name"])

Bien que la plupart des actions soient disponibles via le SDK Amazon S3 V2, il n'est possible de répertorier les objets qu'avec la méthode disponible dans le SDK Amazon S3 V1. Les exemples suivants montrent comment utiliser cette méthode pour répertorier des objets :

Java

Pour plus d'informations, consultez la documentation de référence de l'API Cloud Storage en langage Java.

import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.client.builder.AwsClientBuilder;

import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.AmazonS3ClientBuilder;
import com.amazonaws.services.s3.model.ObjectListing;
import com.amazonaws.services.s3.model.S3ObjectSummary;

import java.util.List;

public class ListGcsObjects {
  public static void listGcsObjects(String googleAccessKeyId,
      String googleAccessKeySecret, String bucketName) {

    // String googleAccessKeyId = "your-google-access-key-id";
    // String googleAccessKeySecret = "your-google-access-key-secret";
    // String bucketName = "bucket-name";

    // Create a BasicAWSCredentials using Cloud Storage HMAC credentials.
    BasicAWSCredentials googleCreds = new BasicAWSCredentials(googleAccessKeyId,
        googleAccessKeySecret);

    // Create a new client and do the following:
    // 1. Change the endpoint URL to use the Google Cloud Storage XML API endpoint.
    // 2. Use Cloud Storage HMAC Credentials.
    AmazonS3 interopClient = AmazonS3ClientBuilder.standard()
            .withEndpointConfiguration(
                new AwsClientBuilder.EndpointConfiguration(
                    "https://storage.googleapis.com", "auto"))
            .withCredentials(new AWSStaticCredentialsProvider(googleCreds))
            .build();

    // Call GCS to list current objects
    ObjectListing objects = interopClient.listObjects(bucketName);

    // Print objects names
    System.out.println("Objects:");
    for (S3ObjectSummary object : objects.getObjectSummaries()) {
      System.out.println(object.getKey());
    }

    // Explicitly clean up client resources.
    interopClient.shutdown();
  }
}

Python

Pour plus d'informations, consultez la documentation de référence de l'API Cloud Storage en langage Python.

import boto3

def list_gcs_objects(google_access_key_id, google_access_key_secret,
                     bucket_name):
    """Lists GCS objects using boto3 SDK"""
    # Create a new client and do the following:
    # 1. Change the endpoint URL to use the
    #    Google Cloud Storage XML API endpoint.
    # 2. Use Cloud Storage HMAC Credentials.

    client = boto3.client("s3", region_name="auto",
                          endpoint_url="https://storage.googleapis.com",
                          aws_access_key_id=google_access_key_id,
                          aws_secret_access_key=google_access_key_secret)

    # Call GCS to list objects in bucket_name
    response = client.list_objects(Bucket=bucket_name)

    # Print object names
    print("Objects:")
    for blob in response["Contents"]:
        print(blob["Key"])

Lorsque vous utilisez l'API XML de Cloud Storage dans un scénario de migration simple, la spécification de l'identificateur de signature AWS dans l'en-tête Authorization informe Cloud Storage de l'utilisation des en-têtes x-amz-* et de la syntaxe XML LCA d'Amazon S3 dans votre requête.

Définir un projet par défaut

Pour utiliser Cloud Storage dans un scénario de migration simple, vous devez choisir un projet par défaut. Lorsque vous choisissez un projet par défaut, vous indiquez à Cloud Storage le projet à utiliser pour des opérations telles que le service GET ou le bucket PUT.

Pour définir un projet par défaut, procédez comme suit :

  1. Ouvrez la page Paramètres Cloud Storage dans la console Google Cloud Platform.
  2. Sélectionnez Interopérabilité.
  3. Cliquez sur Définir cet ID de projet comme mon projet par défaut.

    Si le projet est déjà le projet par défaut, vous verrez le message ID de projet est votre projet par défaut.

Ce projet est maintenant défini comme votre projet par défaut. Vous pouvez modifier votre projet par défaut à tout moment en choisissant un projet différent et en lui activant un accès interopérable.

Gérer les clés de développeur pour une migration simple

Pour utiliser l'API XML de Cloud Storage dans un scénario de migration simple, vous devez utiliser le code d'authentification HMAC (Hash-based Message Authentification Code) avec les clés de développeur de Cloud Storage. Les clés de développeur comprennent une clé d'accès et une clé secrète. Une clé d'accès est une chaîne alphanumérique de 24 caractères, liée à votre compte Google. Toutes les requêtes Cloud Storage authentifiées, à l'exception de celles utilisant une authentification basée sur les cookies, doivent utiliser une clé d'accès dans la requête pour que le système de Cloud Storage sache qui en est l'auteur. Voici un exemple de clé d'accès :

GOOGTS7C7FUP3AIRVJTE2BCD

Une clé secrète est une chaîne codée en base64 de 40 caractères liée à une clé d'accès spécifique. Une clé secrète est une clé prépartagée que seuls vous et le système de Cloud Storage connaissez. Vous devez utiliser votre clé secrète pour signer toutes les requêtes dans le cadre du processus d'authentification. Voici un exemple de clé secrète :

bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ

Pour générer une clé de développeur, procédez comme suit :

  1. Ouvrez la page Paramètres Cloud Storage dans la console Google Cloud Platform.
  2. Sélectionnez Interopérabilité.
  3. Si vous n'avez pas encore configuré l'interopérabilité, cliquez sur Activer l'accès interopérable.
  4. Cliquez sur Créer une clé.

Conseils de sécurité pour l'utilisation de clés de développeur

Vous pouvez créer jusqu'à cinq clés de développeur. Cela est utile si vous travaillez sur plusieurs projets différents et que vous souhaitez utiliser des clés de développeur différentes pour chaque projet.

Vous pouvez également utiliser l'outil de gestion de clés pour supprimer vos clés de développeur et en créer de nouvelles. Cela est souhaitable si vous pensez que quelqu'un d'autre utilise vos clés de développeur ou si vous devez les modifier dans le cadre d'une rotation des clés, ce qui constitue une bonne pratique de sécurité. Si vous avez des clés de développeur et que vous souhaitez en créer de nouvelles, nous vous recommandons de mettre à jour votre code en spécifiant les nouvelles clés de développeur avant de supprimer les anciennes. Lorsque vous supprimez des clés de développeur, celles-ci deviennent immédiatement non valides et ne peuvent plus être restaurées.

S'authentifier dans un scénario de migration simple

En-tête "Authorization"

Pour les opérations nécessitant une authentification dans le cadre d'un scénario de migration simple, vous devez inclure un en-tête de requête d'autorisation Authorization comme vous le feriez pour les requêtes adressées à Amazon S3. La syntaxe de l'en-tête Authorization pour une requête Amazon S3 est la suivante :

Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/CREDENTIAL_SCOPE, SignedHeaders=SIGNED_HEADERS, Signature=SIGNATURE

Dans un scénario de migration simple, vous modifiez uniquement l'en-tête pour utiliser votre clé d'accès de développeur Google et vous vous assurez que la Signature qui y est jointe soit calculée avec votre clé secrète de développeur Google :

Authorization: ALGORITHM Credential=GOOG-ACCESS-KEY/CREDENTIAL_SCOPE, SignedHeaders=SIGNED_HEADERS, Signature=SIGNATURE

L'en-tête Authorization comporte les parties suivantes :

  • ALGORITHM : l'algorithme de signature et la version dont vous vous servez. L'utilisation de AWS4-HMAC-SHA256 indique que vous utilisez une signature HMAC V4 et que vous avez l'intention d'envoyer des en-têtes x-amz-*. Vous pouvez également vous servir de GOOG4-HMAC-SHA256, ce qui indiquerait que vous utilisez une signature HMAC V4 et que vous avez l'intention d'envoyer des en-têtes x-goog-*.

  • GOOG-ACCESS-KEY : la clé d'accès identifie l'entité qui émet et signe la requête. Dans une migration simple, remplacez l'ID de clé d'accès Amazon Web Services (AWS) que vous utilisez pour accéder à Amazon S3 par votre clé d'accès de développeur Google. Cette clé commence par GOOG.

  • CREDENTIAL_SCOPE : le champ d'application des identifiants est une chaîne possédant la structure suivante :

    DATE/LOCATION/SERVICE/REQUEST_TYPE
    • DATE : date au format AAAAMMJJ.
    • LOCATION : la région dans laquelle réside ou sera créée la ressource.
    • SERVICE : le nom du service.
    • REQUEST_TYPE : le type de requête.

    Voici à quoi ressemble un exemple de champ d'application des identifiants de style Amazon S3 :

    20150830/us-east-1/iam/aws4_request

    Dans une migration simple, vous n'avez pas besoin de changer le champ d'application des identifiants si vous utilisez AWS4-HMAC-SHA256 comme valeur pour ALGORITHM. Si vous souhaitez vous servir de GOOG4-HMAC-SHA256, remplacez aws4_request par goog4_request.

  • SIGNED_HEADERS : liste des noms des en-têtes, séparés par des points-virgules, devant être inclus pour signer cette requête. Tous les en-têtes doivent être en lettres minuscules et triés par code de caractère.

    Voici un exemple de chaîne d'en-têtes signée de style Amazon S3 :

    content-type;host;x-amz-date

    Dans une migration simple, vous n'avez pas besoin de modifier la chaîne d'en-têtes signée.

  • SIGNATURE : le hachage cryptographique de la chaîne à signer ayant permis d'authentifier la requête. La signature est créée à l'aide de l'algorithme HMAC-SHA256 en tant que fonction de hachage, ainsi que d'une clé dérivée de votre clé secrète et du champ d'application des identifiants en tant que clé cryptographique. Le condensé obtenu est ensuite encodé en base64. Lorsque Cloud Storage reçoit votre requête signée, il utilise la clé d'accès pour rechercher votre clé secrète et vérifier que c'est bien vous qui êtes à l'origine de la signature. Pour en savoir plus sur l'obtention d'une clé d'accès et d'une clé secrète, consultez la section Gérer les clés de développeur pour l'accès dans un scénario de migration simple.

    Dans une migration simple, remplacez la clé secrète d'accès AWS par votre clé secrète de développeur Google pour obtenir votre clé cryptographique.

Calcul d'authentification

Cette section décrit le processus d'authentification d'une requête API XML dans un scénario de migration simple. Bien que cette section puisse être utilisée pour développer votre propre code afin de signer des requêtes, elle est principalement destinée à être utilisée pour la vérification si vous avez déjà des outils ou des bibliothèques qui signent vos requêtes vers Amazon S3. Dans ce cas, vous continuerez à utiliser ces outils pour accéder à Cloud Storage à l'aide de l'API XML, avec les modifications indiquées ici.

Cette méthode d'authentification fournit à la fois une identité et une authentification forte sans révéler votre clé secrète. Le fait de fournir à la fois une identité et une authentification pour chaque requête permet de garantir le traitement de chaque requête Cloud Storage avec un compte d'utilisateur spécifique et avec l'autorisation de ce compte d'utilisateur. Cela est possible car votre clé secrète n'est connue que du système Cloud Storage et de vous-même. Lorsque vous envoyez une requête, le système Cloud Storage utilise votre clé secrète pour calculer la même signature pour la requête que celle que vous avez calculée lors de l'émission la requête. Si les signatures correspondent, le système Cloud Storage sait que vous seul pouvez être à l'origine de la requête.

Le pseudo-code suivant montre comment créer la signature pour l'en-tête "Authorization" :

Signature = HexEncode(HMAC-SHA256(SiginingKey, StringToSign))

Pour créer la signature, vous devez utiliser une fonction de hachage cryptographique appelée HMAC-SHA256. Il s'agit d'un code d'authentification de message (MAC, Message Authentication Code) par hachage, décrit dans la RFC 4868. Il nécessite deux paramètres d'entrée encodés en UTF-8 : une clé de signature et une chaîne à signer.

La clé de signature est dérivée de votre clé secrète Cloud Storage, et elle est spécifique à la date, l'emplacement, le service et le type de requête associés à votre requête. En outre, ces valeurs doivent correspondre à celles spécifiées dans le champ d'application des identifiants. Le pseudo-code suivant illustre la création de la clé de signature :

key_date = HMAC-SHA256("AWS4" + GOOG-ACCESS-KEY, "YYYYMMDD")
key_region = HMAC-SHA256(key_date, "us-east-1")
key_service = HMAC-SHA256(key_region, "s3")
signing_key = HMAC-SHA256(key_service, "aws4_request")

GOOG-ACCESS-KEY identifie l'entité qui émet et signe la requête.

La chaîne de caractères à signer contient des méta-informations concernant votre requête et la requête canonique que vous souhaitez signer. Le pseudo-code suivant montre comment construire la chaîne de caractères à signer, y compris l'utilisation de sauts de ligne entre chaque élément :

SigningAlgorithm
RequestDateTime
CredentialScope
HashedCanonicalRequest

La chaîne à signer se compose des éléments suivants :

  • SigningAlgorithm : pour une migration simple, il doit s'agir de l'algorithme AWS4-HMAC-SHA256.
  • RequestDateTime : date et heure actuelles au format ISO 8601 : YYYYMMDD'T'HHMMSS'Z'.
  • CredentialScope : le champ d'application des identifiants pour la requête de signature de la chaîne à signer, comme expliqué dans la section En-tête "Authorization".
  • HashedCanonicalRequest : hachage SHA-256 de la requête canonique, encodé en hexadécimal. Utilisez une fonction de hachage SHA-256 pour créer une valeur de hachage de la requête canonique. Votre langage de programmation doit disposer d'une bibliothèque permettant de créer des hachages SHA-256. Voici un exemple de valeur de hachage :

    436b7ce722d03b17d3f790255dd57904f7ed61c02ac5127a0ca8063877e4e42c

Vous trouverez ci-dessous un exemple de chaîne de caractères à signer :

AWS4-HMAC-SHA256
20190301T190859Z
20190301/us-east-1/s3/aws4_request
54f3076005db23fbecdb409d25c0ccb9fb8b5e24c59f12634654c0be13459af0

Requête canonique

La requête canonique est un format de requête HTTP normalisé qui inclut des informations sur la requête que vous souhaitez signer. Cela garantit que, lorsque Cloud Storage reçoit la requête, il est en mesure de calculer la même signature que celle que vous avez calculée. Si votre version et la version calculée par Cloud Storage ne correspondent pas, la requête échoue.

La requête canonique doit posséder la structure suivante et utiliser des sauts de ligne entre chaque élément :

HTTP_VERB
PATH_TO_RESOURCE
CANONICAL_QUERY_STRING
CANONICAL_HEADERS

SIGNED_HEADERS
HexEncode(HMAC-SHA256(REQUEST_PAYLOAD))

La requête canonique se compose des éléments suivants :

  • HTTP_VERB : le verbe HTTP à utiliser avec la requête signée. Pour obtenir la liste des valeurs autorisées, consultez la section Verbes HTTP.

  • PATH_TO_RESOURCE : le chemin d'accès à la ressource, commençant après le nom de l'hôte.

  • CANONICAL_QUERY_STRING : les paramètres de chaîne de requête que les requêtes utilisant l'URL signée doivent inclure. Ajoutez des paramètres de chaîne de requête par ordre alphabétique et séparez-les à l'aide du caractère &.

  • CANONICAL_HEADERS : les paires name:value pour les en-têtes de requêtes que les requêtes utilisant l'URL signée doivent inclure, y compris les en-têtes d'extension. Ajoutez des en-têtes par ordre alphabétique et séparez-les à l'aide du caractère \n.

  • SIGNED_HEADERS : la liste des noms des en-têtes canoniques CANONICAL_HEADERS. Pour créer la liste des en-têtes signés, convertissez tous les noms des en-têtes en minuscules, triez-les par code de caractère et utilisez un point-virgule pour séparer les noms d'en-tête.

  • HexEncode(HMAC-SHA256(REQUEST_PAYLOAD)) : la charge utile de la requête, après hachage SHA-256 et encodage en hexadécimal. Cette chaîne doit figurer sur la dernière ligne de la requête canonique. Si la charge utile est vide, utilisez une chaîne vide comme entrée de la fonction de hachage. La chaîne ci-dessous constitue un exemple de charge utile hachée (charge utile vide) :

    3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Si vous avez suivi le pseudo-code de requête canonique présenté ci-dessus, et que vous avez combiné tous ces éléments, vous devriez obtenir une chaîne de requête canonique semblable à l'exemple ci-dessous :

GET
/

host:storage.googleapis.com
x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
x-amz-date:20190301T190859Z

host;x-amz-content-sha256;x-amz-date
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Exemple de requête d'authentification

Les exemples suivants permettent d'importer un objet nommé /europe/france/paris.jpg dans un bucket my-travel-maps, d'appliquer la LCA public-read prédéfinie et de définir un en-tête de métadonnées personnalisé pour les examinateurs. Voici la requête pour un bucket dans Amazon S3 :

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Mon, 11 Mar 2019 23:46:19 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
x-amz-date:20190311T192918Z
x-amz-meta-reviewer: joe,jane
Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20190311/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-acl;x-amz-date;x-amz-meta-reviewer, Signature=SIGNATURE

Voici la requête pour un bucket dans Cloud Storage :

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Mon, 11 Mar 2019 23:46:19 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
x-amz-date:20190311T192918Z
x-amz-meta-reviewer: joe,jane
Authorization: AWS4-HMAC-SHA256 Credential=GOOG-ACCESS-KEY/20190311/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-acl;x-amz-date;x-amz-meta-reviewer, Signature=SIGNATURE

Voici la requête canonique correspondante ayant été créée pour cette requête :

PUT
/europe/france/paris.jpg

content-length:888814
content-type:image/jpg
host:my-travel-maps.storage.googleapis.com
x-amz-acl:public-read
x-amz-date:20190311T192918Z
x-amz-meta-reviewer:joe,jane

content-length,content-type,host,x-amz-acl,x-amz-date,x-amz-meta-reviewer
82e3da8b3f35989512e8d428add7eca73ab0e5f36586e66fbad8e1051343cbd2

Voici la chaîne de caractères à signer correspondante ayant été créée pour cette requête :

AWS4-HMAC-SHA256
20190311T192918Z
20190311/us-east-1/s3/aws4_request
73918a5ff373d7a03e406fbf9ea35675396b06fca2af76c27a5c451fa783ef65

Cette requête n'ayant pas fourni d'en-tête Content-MD5, une chaîne vide est affichée dans le message (deuxième ligne).

Contrôle des accès dans un scénario de migration simple

Pour être compatible avec les migrations simples, Cloud Storage accepte les LCA produites par Amazon S3. Dans un scénario de migration simple, vous utiliserez AWS comme identifiant de signature indiquant à Cloud Storage de s'attendre à une syntaxe LCA utilisant la syntaxe XML de la LCA d'Amazon S3. Vous devez vous assurer que les LCA d'Amazon S3 que vous utilisez sont mappées sur le modèle LCA de Cloud Storage. Par exemple, si vos outils et bibliothèques utilisent la syntaxe LCA d'Amazon S3 pour accorder une autorisation de bucket WRITE, ils doivent également octroyer une autorisation de bucket READ, car les autorisations de Cloud Storage sont concentriques. Il n'est pas nécessaire de spécifier à la fois les autorisations WRITE et READ lorsque vous accordez l'autorisation WRITE à l'aide de la syntaxe de Cloud Storage.

Cloud Storage prend en charge la syntaxe LCA d'Amazon S3 dans les scénarios suivants :

  • En cas de requête adressée à Cloud Storage pour récupérer des LCA (par exemple, une requête "GET Object" ou "GET Bucket"), Cloud Storage renvoie la syntaxe LCA d'Amazon S3.
  • Dans une requête adressée à Cloud Storage pour appliquer des listes de contrôle d'accès (par exemple, une requête "PUT Object" ou "PUT Bucket"), Cloud Storage s'attend à recevoir la syntaxe LCA d'Amazon S3.

L'en-tête Authorization dans un scénario de migration simple utilisera AWS pour l'identification de signature, mais avec votre clé d'accès Google.

Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/CREDENTIAL_SCOPE, SignedHeaders=SIGNED_HEADERS, Signature=SIGNATURE

L'exemple suivant est une requête GET adressée à Cloud Storage pour renvoyer les LCA à un objet.

GET europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Thu, 21 Feb 2019 23:50:10 GMT
Content-Type: application/xml
X-Amz-Date: 20190221T235010Z
Authorization: AWS4-HMAC-SHA256 Credential=GOOGMC5PDPA5JLZYQMHQHRAX/20190221/region/s3/aws4_request, SignedHeaders=host;x-amz-date, Signature=29088b1d6dfeb2549f6ff67bc3744abb7e45475f0ad60400485805415bbfc534

La réponse à la requête inclut la LCA utilisant la syntaxe d'Amazon S3.

<?xml version='1.0' encoding='UTF-8'?>
<AccessControlPolicy>
    <Owner>
        <ID>00b4903a972faa8bcce9382686e9129676f1cd6e5def1f5663affc2ba4652490
        </ID>
        <DisplayName>OwnerName</DisplayName>
    </Owner>
    <AccessControlList>
        <Grant>
            <Grantee xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
                xsi:type='CanonicalUser'>
                <ID>00b4903a972faa8bcce9382686e9129676f1cd6e5def1f5663affc2ba4652490</ID>
                <DisplayName>UserName</DisplayName>
            </Grantee>
            <Permission>FULL_CONTROL</Permission>
        </Grant>
    </AccessControlList>
</AccessControlPolicy>

L'exemple suivant est une requête PUT adressée à Cloud Storage pour définir les LCA à un objet. L'exemple montre un corps de requête avec la syntaxe LCA d'Amazon S3.

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Thu, 21 Feb 2019 23:50:10 GMT
Content-Type: application/xml
Content-Length: 337
X-Amz-Date: 20190221T235010Z
Authorization: AWS4-HMAC-SHA256 Credential=GOOGMC5PDPA5JLZYQMHQHRAX/20190221/region/s3/aws4_request, SignedHeaders=host;x-amz-date, Signature=29088b1d6dfeb2549f6ff67bc3744abb7e45475f0ad60400485805415bbfc534

<?xml version='1.0' encoding='utf-8'?>
<AccessControlPolicy>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AmazonCustomerByEmail">
        <EmailAddress>jane@gmail.com</EmailAddress>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

Enfin, dans un scénario de migration simple, vous pouvez également utiliser l'identifiant de signature GOOG1 dans l'en-tête Authorization. Dans ce cas, vous devez utiliser la syntaxe LCA de Cloud Storage et vous assurer que tous vos en-têtes sont des en-têtes Google, sous la forme x-goog-*. Bien que cela soit une possibilité, nous vous recommandons de passer à une migration complète telle que décrite ci-dessous afin de tirer pleinement parti des avantages de Cloud Storage.

Migration complète

Une migration complète d'Amazon S3 vers Cloud Storage vous permet de bénéficier de toutes les fonctionnalités de Cloud Storage, y compris les suivantes :

Compatibilité avec les comptes de service
Les comptes de service sont utiles pour les interactions de serveur à serveur qui ne nécessitent pas l'intervention de l'utilisateur final. Pour plus d'informations, consultez la page Comptes de service.
Compatibilité avec plusieurs projets
Le fait d'avoir plusieurs projets vous permet en effet d'exécuter plusieurs instances du service Cloud Storage. Cela vous permet de séparer différentes fonctionnalités ou services de votre application ou de votre entreprise, selon vos besoins. Pour plus d'informations, consulter la page Utiliser des projets.
Authentification OAuth 2.0
OAuth 2.0 repose sur SSL pour la sécurité, au lieu de demander à votre application de procéder directement à la signature cryptographique, ce qui facilite également la mise en œuvre. OAuth permet à votre application de demander l'accès aux données associées au compte Google d'un utilisateur, et l'accès peut être limité à plusieurs niveaux, y compris en lecture seule, en lecture-écriture et en contrôle total. Pour plus d'informations, consultez la page Authentification OAuth 2.0.

Pour une migration complète d'Amazon S3 vers Cloud Storage, vous devez apporter les modifications suivantes :

  • Remplacez les en-têtes x-amz-* existants par les en-têtes x-goog-*.
  • Remplacez le fichier XML LCA (Liste de contrôle d'accès) d'AWS par le fichier XML LCA de Cloud Strorage correspondant (reportez-vous à la section Spécifier les LCA de buckets et d'objets).
  • Définissez l'en-tête x-goog-project-id dans vos requêtes. Notez que dans un scénario de migration simple, vous avez choisi un projet par défaut pour toutes les requêtes. Cela n'est pas nécessaire dans le cas d'une migration complète.
  • Préparez-vous à utiliser l'authentification OAuth 2.0 comme décrit dans le document Authentification OAuth 2.0. La première étape consiste à enregistrer votre application (depuis laquelle vous allez envoyer des requêtes) auprès de Google. Lorsque vous utilisez OAuth 2.0, votre en-tête Authorization ressemble à ceci :

    Authorization: Bearer <oauth2_token>

Contrôle des accès dans une migration complète

Cette section présente quelques exemples de contrôle des accès pour vous aider dans votre migration d'Amazon S3 vers Cloud Storage. Pour en savoir plus sur le contrôle des accès dans Cloud Storage, consulter la section Contrôle des accès.

Dans Cloud Storage, il existe plusieurs façons d'appliquer des LCA à des buckets et à des objets (consultez la page Spécifier les LCA de buckets et d'objets). Il existe deux manières de spécifier les LCA analogues à celle d'Amazon S3 :

  • Le paramètre de chaîne de requête acl permettant d'appliquer des LCA à des champs d'application spécifiques.
  • L'en-tête de requête x-goog-acl vous permet d'appliquer des listes de contrôle d'accès prédéfinies, parfois appelées listes de contrôle d'accès standardisées.

Utiliser le paramètre de chaîne de requête "acl"

Vous pouvez utiliser le paramètre de chaîne de requête acl pour une requête Cloud Storage exactement de la même manière que pour une requête Amazon S3. Le paramètre acl est utilisé avec la méthode PUT pour appliquer des listes de contrôle d'accès aux éléments suivants : un objet existant, un bucket existant ou un bucket que vous créez. Lorsque vous utilisez le paramètre de chaîne de requête acl dans une requête PUT, vous devez attacher un document XML (à l'aide de la syntaxe LCA de Cloud Storage) au corps de votre requête. Le document XML contient les entrées individuelles de la LCA que vous souhaitez appliquer au bucket ou à l'objet.

L'exemple suivant montre une requête PUT adressée à Amazon S3 qui utilise le paramètre de chaîne de requête acl. Les LCA sont définies dans un document XML envoyé dans le corps de la requête. La requête PUT modifie les LCA sur un objet nommé europe/france/paris.jpg qui se trouve dans un bucket nommé my-travel-maps. La LCA accorde à jane@gmail.com l'autorisation FULL_CONTROL.

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Wed, 06 Nov 2013 19:28:18 GMT
Content-Length: 598
Content-Type: application/xml
Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20131106/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;date;host, Signature=4c45f25bb679fdab0de5a287625d6a143414728d93c9aeb9f4cc91c33a1c45fg

<?xml version='1.0' encoding='utf-8'?>
<AccessControlPolicy>
  <Owner>
    <ID>5a6557ba40f7c86496ffceae789fcd888abc1b62a7149873a0fe12c0f60a7d95</ID>
    <DisplayName>ownerEmail@example.com</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>fd447671d60b979f78ee6fcec7b22afc80e6b26a4db16eed01afb8064047949b</ID>
        <DisplayName>jane@gmail.com</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

Voici la même requête adressée à Cloud Storage :

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 19:37:33 GMT
Content-Length: 268
Content-Type: application/xml
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<?xml version='1.0' encoding='utf-8'?>
<AccessControlList>
  <Entries>
  <Entry>
    <Permission>FULL_CONTROL</Permission>
    <Scope type="UserByEmail">
      <EmailAddress>jane@gmail.com</EmailAddress>
    </Scope>
  </Entry>
  </Entries>
</AccessControlList>

Notez que Cloud Storage ne requiert pas d'élément <Owner/> dans le document XML de la LCA. Pour plus d'informations, consultez la section Liste de contrôle d'accès aux objets par défaut.

Vous pouvez également récupérer des listes de contrôle d'accès aux objets et aux buckets à l'aide du paramètre de chaîne de requête acl avec la méthode GET. Les LCA sont décrites dans un document XML joint au corps de la réponse. Vous devez disposer de l'autorisation FULL_CONTROL pour appliquer ou récupérer des LCA à un objet ou un bucket.

Appliquer des LCA avec un en-tête de requête d'extension

Vous pouvez utiliser l'en-tête x-goog-acl dans une requête Cloud Storage pour appliquer des LCA prédéfinies à des buckets et des objets de la même manière que vous utiliseriez l'en-tête x-amz-acl dans une requête Amazon S3. Vous utilisez généralement l'en-tête x-goog-acl (x-amz-acl) pour appliquer une LCA prédéfinie à un bucket ou à un objet lors de la création ou du téléchargement du bucket ou de l'objet. Les LCA prédéfinies de Cloud Storage sont semblables aux LCA prédéfinies d'Amazon S3, y compris les LCA privées, à lecture publique, à lecture/écriture publique, et d'autres encore. Pour obtenir la liste des LCA prédéfinies de Cloud Storage, consulter le document Listes de contrôle d'accès prédéfinies.

L'exemple suivant montre une requête d'objet PUT qui applique la LCA public-read à un objet nommé europe/france/paris.jpg en cours d'importation vers un bucket my-travel-maps dans Amazon S3.

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Wed, 06 Nov 2013 20:48:42 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20131106/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;date;host, Signature=808150c37dbd1b425b2398421d6fc3dd6d4942dfaae9e519fd5835aa62fd62ab

<888814 bytes in entity body>

Voici la même requête adressée à Cloud Storage :

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 20:49:57 GMT
Content-Length: 888814
Content-Type: image/jpg
x-goog-acl: public-read
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<888814 bytes in entity body>

Vous pouvez également utiliser l'en-tête x-goog-acl pour appliquer une LCA prédéfinie à un bucket ou à un objet existant. Pour ce faire, ajoutez le paramètre de chaîne de requête acl dans votre requête, mais n'y incluez pas de document XML. L'application d'une LCA prédéfinie à un objet ou à un bucket existant est utile si vous souhaitez passer d'une LCA prédéfinie à une autre ou mettre à jour des LCA personnalisées et les configurer en tant que LCA prédéfinies. Par exemple, la requête d'objet PUT suivante applique la LCA prédéfinie private à un objet nommé europe/france/paris.jpg qui se trouve dans un bucket my-travel-maps.

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 00:26:36 GMT
Content-Length: 0
x-goog-acl: private
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<empty entity body>

Pour plus d'informations sur la gestion des LCA, consultez la section Gérer le contrôle des accès.

Migrer depuis Amazon  S3 vers Cloud Storage - Méthodes de requête

Cloud Storage est compatible avec les mêmes méthodes de requête HTTP standards pour la lecture et l'écriture de données dans vos buckets que celles utilisées dans Amazon S3. Par conséquent, la majorité des outils et bibliothèques que vous utilisez actuellement avec Amazon S3 fonctionneront tels quels avec Cloud Storage. Cloud Storage est compatible avec les méthodes de requête suivantes :

  • Requête de service pour GET.
  • Requêtes de bucket, y compris PUT, GET et DELETE.
  • Requêtes d'objet, y compris GET, POST, PUT, HEAD et DELETE.

Pour plus d'informations, consultez le document Méthodes de référence de l'API XML. N'oubliez pas que lorsque vous envoyez des requêtes à Cloud Storage, vous devez modifier le corps de la requête, le cas échéant, afin d'utiliser la syntaxe Cloud Storage appropriée. Par exemple, lorsque vous créez une configuration de cycle de vie pour un bucket, utilisez le XML de cycle de vie Cloud Storage, qui est différent du XML de cycle de vie d'Amazon S3.

Il existe quelques différences entre l'API XML de Cloud Storage et celui d'Amazon S3. En voici un résumé, avec les alternatives suggérées pour Cloud Storage :

Fonctionnalité Amazon S3 Fonctionnalité de l'API XML de Cloud Storage
Importation en plusieurs parties
POST /<object-name>, PUT /<object-name>

Dans l'API XML de Cloud Storage, vous pouvez télécharger une série d'objets de type composant, en effectuant un téléchargement séparé pour chaque composant. Vous pouvez ensuite composer les objets pour en faire un seul objet composite.

Remarque : Bien que l'API JSON offre une fonctionnalité d'importation en plusieurs parties, cette dernière est utilisée pour envoyer des métadonnées avec des données d'objet. Cela n'est pas équivalent à la fonctionnalité d'importation en plusieurs parties de S3.

Paramètres de chaîne de requête du bucket GET/POST :
  • "policy" : Utilisation des stratégies de bucket Amazon S3.
  • "website" : Configuration de sites Web de bucket.
  • "tagging" : Marquage des buckets à des fins de répartition des coûts.
  • "notification" : Notification pour les événements de bucket.
  • "requestPayment" : Configuration de la personne assumant les frais de la requête et du téléchargement de données à partir d'un bucket.
Alternatives :
  • "policy" : Les LCA de Cloud Storage, l'appartenance à une équipe de projet et la possibilité d'utiliser plusieurs projets sont des alternatives qui répondent à de nombreux scénarios dans lesquels des stratégies de bucket sont utilisées.
  • "website" : Exécutez la commande web gsutil pour gérer des sites Web, ou essayez l'API JSON (consultez le document sur les buckets).
  • "tagging" : Utilisez plusieurs projets pour suivre différents centres de coûts. Pour plus d'informations sur les projets, consultez le document Gestion des projets.
  • "notification" : Utilisez les notifications Cloud Pub/Sub de gsutil ou de l'API JSON.
  • "requestPayment" : Utilisez plusieurs projets avec différents profils de facturation pour gérer les personnes assumant les frais des requêtes et des données téléchargées à partir d'un bucket. Pour plus d'informations sur la configuration de la facturation, consultez la section Facturation de la documentation d'aide de la console API Google.
Suppression de plusieurs objets.
POST /?delete

Utilisez la commande rm gsutil pour supprimer facilement plusieurs objets. La commande rm accepte l'option "-m" pour effectuer des suppressions parallèles (suppressions multithread/multitraitement).

L'API JSON accepte également l'envoi de requêtes par lots afin de réduire le nombre de connexions HTTP établies par votre client.

Migrer depuis Amazon S3 vers Cloud Storage - En-têtes

Cloud Storage utilise plusieurs en-têtes HTTP standards ainsi que plusieurs en-têtes HTTP personnalisés (extensions). Si vous effectuez une transition depuis Amazon S3 vers Cloud Storage, vous pouvez convertir vos en-têtes Amazon S3 personnalisés en en-têtes Cloud Storage personnalisés équivalents ou en une fonctionnalité semblable, comme indiqué dans le tableau ci-dessous.

En-tête Amazon S3 En-tête Cloud Storage
x-amz-acl x-goog-acl
x-amz-date x-goog-date
x-amz-meta-* x-goog-meta-*
x-amz-grant-* x-goog-acl avec une valeur LCA prédéfinie
x-amz-copy-source x-goog-copy-source
x-amz-metadata-directive x-goog-metadata-directive
x-amz-copy-source-if-match x-goog-copy-source-if-match
x-amz-copy-source-if-none-match x-goog-copy-source-if-none-match
x-amz-copy-source-if-unmodified-since x-goog-copy-source-if-unmodified-since
x-amz-copy-source-if-modified-since x-goog-copy-source-if-modified-since
x-amz-server-side-encryption Facultatif. Cloud Storage chiffre automatiquement toutes les données avant qu'elles ne soient écrites sur le disque. Pour plus d'informations, consultez le document Chiffrement.
x-amz-storage-class Vous pouvez spécifier une classe de stockage lors de la création d'un bucket. Pour plus d'informations, consultez le document Classes de stockage.
x-amz-mfa Utilisez l'authentification OAuth 2.0.
x-amz-website-redirect-location, x-amz-copy-source-range Non disponible

Groupes de discussion et prise en charge de la compatibilité de l'API XML avec Amazon S3

Le groupe de discussion gs de Cloud Storage, qui gérait auparavant les problèmes d'interopérabilité et de migration des API XML, est en mode archive. Le forum de discussion est désormais accessible sur Stack Overflow à l’aide de la balise google-cloud-storage. Consultez la page Ressources et assistance pour en savoir plus sur les forums de discussion et l'abonnement aux annonces.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.