Como migrar do Amazon S3 para o Cloud Storage

Nesta página, descreveremos como migrar do Amazon Simple Storage Service (Amazon S3) para o Cloud Storage se você for um usuário que envia solicitações usando uma API. Se você não estiver usando o Amazon S3 atualmente e quiser enviar solicitações usando a API Cloud Storage, comece aqui: Visão geral da API XML.

Se você é novo no Cloud Storage e não usa a API diretamente, considere o uso do Console do Google Cloud Platform para definir e gerenciar transferências. O Console do Google Cloud Platform fornece uma interface gráfica para o Cloud Storage que permite realizar muitas de suas tarefas de armazenamento usando apenas um navegador, incluindo a migração de dados do Amazon S3 para o Cloud Storage.

Visão geral da migração

Se você é um usuário do Amazon S3, pode migrar facilmente seus aplicativos que usam o Amazon S3 para o Cloud Storage. Você tem duas opções de migração:

Migração Simples

Essa é a maneira mais fácil de começar a usar o Cloud Storage se você estiver migrando do Amazon S3, porque exige apenas algumas alterações simples nas ferramentas e bibliotecas que você usa atualmente com o Amazon S3. Para mais informações, consulte Migração simples.

Mesmo que uma migração simples permita avançar rapidamente com o Cloud Storage, ela não permite que você use todos os recursos dele. Para aproveitar ao máximo o Cloud Storage, siga as etapas para uma migração completa.

Migração Completa

Uma migração completa do Amazon S3 para o Cloud Storage requer algumas etapas a mais do que uma migração simples, mas o benefício é que você pode usar todos os recursos do Cloud Storage, incluindo suporte a contas de serviço, vários projetos e OAuth 2.0 para autenticação. Para mais informações, consulte Migração completa.

Migração simples

Em uma migração simples do Amazon S3 para o Cloud Storage, você pode usar suas ferramentas e bibliotecas existentes para gerar solicitações REST autenticadas para o Amazon S3 também para enviar solicitações autenticadas para o Cloud Storage. As alterações que você precisa fazer em suas ferramentas e bibliotecas existentes estão descritas nesta seção.

Para configurar uma migração simples, faça isto:

Pronto! Já é possível começar a usar suas ferramentas e bibliotecas atuais para enviar solicitações de código de autenticação de mensagens de hash com chave (HMAC, na sigla em inglês) para o Cloud Storage.

Os exemplos a seguir mostram como listar os intervalos do Cloud Storage usando o SDK do Amazon S3:

Java

Para mais informações, consulte a documentação de referência da API Cloud Storage para 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

Para mais informações, consulte a documentação de referência da API Cloud Storage para 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"])

Embora a maioria das ações esteja disponível usando o SDK do Amazon S3 V2, a listagem de objetos só pode ser realizada usando o método de listagem de objetos do Amazon S3 V1. Os exemplos a seguir demonstram essa listagem de objetos:

Java

Para mais informações, consulte a documentação de referência da API Cloud Storage para 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

Para mais informações, consulte a documentação de referência da API Cloud Storage para 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"])

Quando você usa a API XML do Cloud Storage em um cenário de migração simples, a especificação do identificador de assinatura AWS no cabeçalho Authorization permite que o Cloud Storage espere cabeçalhos x-amz-* e sintaxe XML do ACL do Amazon S3 em sua solicitação.

Como definir um projeto padrão

Para usar o Cloud Storage em um cenário de migração simples, você precisa escolher um projeto padrão. Ao escolher um projeto padrão, você informa ao Cloud Storage que o projeto será usado para operações como o serviço GET ou o intervalo PUT.

Para definir um projeto padrão:

  1. Abra a página Configurações do Cloud Storage no Console do Google Cloud Platform.
  2. Selecione Interoperabilidade.
  3. Clique em Tornar este ID do PROJETO meu projeto padrão.

    Se o projeto já for o projeto padrão, a frase ID DO PROJETO é seu projeto padrão será exibida.

Agora, esse é seu projeto padrão. É possível alterá-lo a qualquer momento escolhendo um projeto diferente e ativando o acesso interoperável para ele.

Como gerenciar chaves de desenvolvedor para uma migração simples

Para usar a API XML do Cloud Storage em um cenário de migração simples, você precisa usar a autenticação de código de mensagem de hash com chave (HMAC) com chaves de desenvolvedor do Cloud Storage. As chaves de desenvolvedor são compostas por uma chave de acesso e um segredo. Uma chave de acesso é uma string alfanumérica de 24 caracteres vinculada à Conta do Google. Todas as solicitações de armazenamento autenticadas do Cloud Storage, exceto aquelas que usam autenticação baseada em cookies, precisam usar uma chave de acesso na solicitação para que o sistema do Cloud Storage saiba quem está fazendo a solicitação. A seguir, um exemplo de chave de acesso:

GOOGTS7C7FUP3AIRVJTE2BCD

Um segredo é uma string codificada com Base-64 de 40 caracteres vinculada a uma chave de acesso específica. Um segredo é uma chave pré-compartilhada que apenas você e o sistema do Cloud Storage conhecem. Você precisa usá-lo para assinar todas as solicitações como parte do processo de autenticação. Veja a seguir um exemplo de segredo:

bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ

Para gerar uma chave de desenvolvedor:

  1. Abra a página Configurações do Cloud Storage no Console do Google Cloud Platform.
  2. Selecione Interoperabilidade.
  3. Se você não configurou a interoperabilidade antes, clique em Ativar acesso à interoperabilidade.
  4. Clique em Criar uma nova chave.

Dicas de segurança para trabalhar com chaves de desenvolvedor

Você pode criar até cinco chaves de desenvolvedor. Isso será útil se você estiver trabalhando em diversos projetos e quiser usar chaves de desenvolvedor diferentes para cada um deles.

Também é possível usar a ferramenta de gerenciamento de chave para excluir suas chaves de desenvolvedor e criar outras novas. Convém fazer isso se você achar que outra pessoa está usando suas chaves de desenvolvedor ou se precisar alterá-las como parte de uma rotação de chave, que é uma prática recomendada de segurança. Se você tiver chaves de desenvolvedor e quiser criar novas chaves, recomendamos primeiro a atualização de seu código com as novas chaves de desenvolvedor antes de excluir as antigas. Quando excluídas, as chaves de desenvolvedor se tornam imediatamente inválidas e não podem ser recuperadas.

Como autenticar em um cenário de migração simples

Cabeçalho de autorização

Para operações em um cenário de migração simples que exigem autenticação, inclua um cabeçalho de solicitação Authorization exatamente como faz para solicitações do Amazon S3. A sintaxe do cabeçalho Authorization para uma solicitação do Amazon S3 é:

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

Em um cenário de migração simples, você só altera o cabeçalho para usar sua chave de acesso do desenvolvedor do Google e garante que a Signature anexada seja calculada com sua chave secreta do desenvolvedor do Google:

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

As partes do cabeçalho Authorization são:

  • ALGORITMO: o algoritmo de assinatura e a versão que você está usando. O uso do AWS4-HMAC-SHA256 indica que você está utilizando uma assinatura HMAC V4 e pretende enviar cabeçalhos x-amz-*. Também é possível usar o GOOG4-HMAC-SHA256, que indica que você está utilizando uma assinatura HMAC V4 e pretende enviar cabeçalhos x-goog-*.

  • GOOG-ACCESS-KEY: a chave de acesso identifica a entidade que está fazendo e assinando a solicitação. Em uma migração simples, substitua o código da chave de acesso da Amazon Web Service (AWS) que você usa para acessar o Amazon S3 com sua chave de acesso de desenvolvedor do Google. Sua chave de acesso do desenvolvedor do Google começa com GOOG.

  • CREDENTIAL_SCOPE: o escopo da credencial é uma string que apresenta a seguinte estrutura:

    DATE/LOCATION/SERVICE/REQUEST_TYPE
    • DATA: data no formato AAAAMMDD.
    • LOCATION: a região em que o recurso reside ou será criado.
    • SERVIÇO: o nome do serviço.
    • REQUEST_TYPE: o tipo de solicitação.

    Um exemplo de um escopo de credencial no estilo do Amazon S3 é semelhante a este:

    20150830/us-east-1/iam/aws4_request

    Em uma migração simples, não é necessário alterar o escopo da credencial se você estiver usando o AWS4-HMAC-SHA256 para o valor de ALGORITMO. Se você quiser usar o GOOG4-HMAC-SHA256, substitua aws4_request por goog4_request.

  • SIGNED_HEADERS: uma lista separada por ponto-e-vírgula de nomes de cabeçalhos que precisam ser incluídos para assinar essa solicitação. Todos os cabeçalhos precisam ser em letra minúscula e classificados por código de caractere.

    Um exemplo de uma string de cabeçalho assinada no estilo do Amazon S3 é semelhante a esta:

    content-type;host;x-amz-date

    Em uma migração simples, você não precisa fazer nenhuma alteração na string de cabeçalho assinada.

  • ASSINATURA: o hash criptográfico da string a ser assinada que permitiu que a solicitação fosse autenticada. A assinatura é criada usando HMAC-SHA256 como a função hash e uma chave derivada de seu escopo secreto e de credencial como a chave criptográfica. O resumo resultante será codificado em Base64. Quando o Cloud Storage recebe sua solicitação assinada, ele usa a chave de acesso para pesquisar o segredo e verificar se você criou a assinatura. Para mais informações sobre como conseguir uma chave secreta e de acesso, consulte Como gerenciar chaves do desenvolvedor para acesso em um cenário de migração simples.

    Em uma migração simples, substitua a chave de acesso secreta da AWS pelo segredo de chave de desenvolvedor do Google para derivar a chave criptográfica.

Cálculo de autenticação

Nesta seção, descreveremos o processo de autenticação de uma solicitação da API XML em um cenário de migração simples. Mesmo que essa seção possa ser usada para desenvolver seu próprio código para assinar solicitações, o objetivo principal dela é servir de uma revisão caso você já tenha ferramentas ou bibliotecas que assinem suas solicitações para o Amazon S3. Nesse caso, você continuará usando essas ferramentas para acessar o Cloud Storage usando a API XML, com as alterações mostradas aqui.

Esse método de autenticação fornece identidade e autenticação sólida, sem revelar seu segredo. O fornecimento de identidade e autenticação em cada solicitação ajuda a garantir que cada solicitação do Cloud Storage seja processada sob uma conta de usuário específica e com a autoridade dessa conta de usuário. Isso é possível porque somente você e o sistema do Cloud Storage sabem seu segredo. Quando você faz uma solicitação, o sistema do Cloud Storage usa seu segredo para calcular a mesma assinatura para a solicitação que você calculou quando fez a solicitação. Se as assinaturas corresponderem, o sistema do Cloud Storage saberá que apenas você pode ter feito a solicitação.

Neste pseudocódigo, você verá como criar a assinatura para o cabeçalho de Autorização:

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

Para criar a assinatura, use uma função de hash criptográfico conhecida como HMAC-SHA256. HMAC-SHA256 é um código de autenticação de mensagem (MAC, na sigla em inglês) baseado em hash. Ele está descrito no RFC 4868 (em inglês). Esse código requer dois parâmetros de entrada, ambos codificados em UTF-8: uma chave de assinatura e uma string para assinar.

A chave de assinatura é derivada da sua chave secreta do Cloud Storage e é específica da data, local, serviço e tipo de solicitação associados à sua solicitação. Além disso, esses valores precisam corresponder aos valores especificados no escopo da credencial. O pseudocódigo a seguir mostra como criar a chave de assinatura:

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

em que GOOG-ACCESS-KEY identifica a entidade que está fazendo e assinando a solicitação.

A string a ser assinada inclui metainformações sobre sua solicitação e sobre a solicitação canônica que você quer assinar. O pseudocódigo a seguir mostra como construir a string a ser assinada, incluindo o uso de novas linhas entre cada elemento:

SigningAlgorithm
RequestDateTime
CredentialScope
HashedCanonicalRequest

A string a ser assinada tem os seguintes componentes:

  • SigningAlgorithm: precisa ser AWS4-HMAC-SHA256 para uma migração simples.
  • RequestDateTime: a data e hora atuais, no formato ISO 8601: YYYYMMDD'T'HHMMSS'Z'.
  • CredentialScope: o escopo da credencial da solicitação para assinar a string, conforme abordado na seção do cabeçalho Authorization.
  • HashedCanonicalRequest: o hash SHA-256 da solicitação canônica, codificado em hexadecimal. Use uma função de hash SHA-256 para criar um valor de hash da solicitação canônica. A linguagem de programação precisa ter uma biblioteca para criar hashes SHA-256. Um exemplo de valor de hash é semelhante a este:

    436b7ce722d03b17d3f790255dd57904f7ed61c02ac5127a0ca8063877e4e42c

Um exemplo de string a ser assinada é semelhante a esta:

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

Pedido canônico

A solicitação canônica é um formato padronizado de uma solicitação HTTP que inclui informações sobre a solicitação que você quer assinar. Isso garante que o Cloud Storage possa calcular a mesma assinatura que você calculou quando receber a solicitação. Se a sua versão e a versão calculada pelo Cloud Storage não corresponderem, a solicitação falhará.

A solicitação canônica precisa ter a seguinte estrutura, incluindo o uso de novas linhas entre cada elemento:

HTTP_VERB
PATH_TO_RESOURCE
CANONICAL_QUERY_STRING
CANONICAL_HEADERS

SIGNED_HEADERS
HexEncode(HMAC-SHA256(REQUEST_PAYLOAD))

A solicitação canônica tem os seguintes componentes:

  • HTTP_VERB: o verbo HTTP a ser usado com a solicitação assinada. Para uma lista de valores permitidos, consulte verbos HTTP.

  • PATH_TO_RESOURCE: o caminho para o recurso, começando após o nome do host.

  • CANONICAL_QUERY_STRING: os parâmetros da string de consulta que precisam estar inclusos nas solicitações que usam a solicitação assinada. Adicione os parâmetros da string de consulta em ordem alfabética e separe cada um por &.

  • CANONICAL_HEADERS: os pares de name:value para os cabeçalhos de solicitação que precisam ser incluídos nas solicitações que utilizam a solicitação assinada, incluindo cabeçalhos de extensão. Adicione cabeçalhos em ordem alfabética e separe cada um por \n.

  • SIGNED_HEADERS: a lista de nomes de cabeçalho de CANONICAL_HEADERS. Para criar a lista de cabeçalhos assinados, converta todos os nomes de cabeçalho em minúsculas, ordene-os por código de caractere e use um ponto-e-vírgula para separar os nomes.

  • HexEncode(HMAC-SHA256(REQUEST_PAYLOAD)): um payload de solicitação em hash SHA-256 codificada em hexadecimal. Essa string precisa aparecer na última linha da solicitação canônica. Se o payload estiver vazio, use uma string vazia como entrada para a função hash. Um exemplo de payload em hash (payload vazio) seria:

    3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Depois de seguir o pseudocódigo canônico de solicitação introduzido anteriormente e combinar todos esses elementos juntos, consiga uma string de solicitação canônica, como no exemplo abaixo:

GET
/

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

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

Exemplo de solicitação de autenticação

Os exemplos a seguir fazem upload de um objeto chamado /europe/france/paris.jpg em um intervalo chamado my-travel-maps, aplicam a public-read predefinida da ACL e definem um cabeçalho de metadados personalizado para revisores. Esta é uma solicitação para um intervalo no 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

Esta é uma solicitação para um intervalo no 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

Esta é uma solicitação canônica correspondente que foi criada para a solicitação acima:

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

Esta é a string a ser assinada correspondente, criada para a solicitação:

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

A solicitação não forneceu um cabeçalho Content-MD5, portanto, uma string vazia é mostrada na segunda linha da mensagem.

Controle de acesso em um cenário de migração simples

Para possibilitar a compatibilidade com migrações simples, o Cloud Storage aceita ACLs produzidas pelo Amazon S3. Em um cenário de migração simples, você usará o AWS como seu identificador de assinatura, que informa ao Cloud Storage para esperar a sintaxe da ACL usando a sintaxe XML do Amazon S3 ACL. É necessário garantir que as ACLs do Amazon S3 usadas sejam mapeadas para o modelo ACL do Cloud Storage. Por exemplo, se as ferramentas e bibliotecas usarem a sintaxe ACL do Amazon S3 para conceder permissão WRITE ao intervalo, elas também precisarão conceder permissão READ ao intervalo, já que as permissões do Cloud Storage são concêntricas. Não é necessário especificar as permissões WRITE e READ ao conceder permissão WRITE usando a sintaxe do Cloud Storage.

O Cloud Storage aceita a sintaxe ACL do Amazon S3 nos cenários a seguir:

  • Em uma solicitação ao Cloud Storage para recuperar ACLs (por exemplo, uma solicitação GET Object ou GET Bucket), o Cloud Storage retorna a sintaxe ACL do Amazon S3.
  • Em uma solicitação ao Cloud Storage para aplicar ACLs (por exemplo, uma solicitação PUT Object ou PUT Bucket), o Cloud Storage espera receber a sintaxe ACL do Amazon S3.

O cabeçalho Authorization em um cenário de migração simples usará AWS para o identificador de assinatura, mas com sua chave de acesso do Google.

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

No exemplo a seguir, mostraremos uma solicitação GET ao Cloud Storage para retornar as ACLs de um objeto.

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

A resposta à solicitação inclui a ACL usando a sintaxe ACL do 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>

No exemplo a seguir, mostraremos uma solicitação PUT ao Cloud Storage para definir as ACLs de um objeto. O exemplo mostra um corpo de solicitação com a sintaxe ACL do 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>

Por fim, em um cenário de migração simples, você também pode usar o identificador de assinatura GOOG1 no cabeçalho Authorization. Nesse caso, é necessário usar a sintaxe ACL do Cloud Storage e garantir que todos os cabeçalhos sejam cabeçalhos do Google, x-goog-*. Mesmo que isso seja possível, recomendamos que você mude para uma migração completa, conforme descrito abaixo, para aproveitar todos os benefícios do Cloud Storage.

Migração completa

Uma migração completa do Amazon S3 para o Cloud Storage permite que você aproveite todos os recursos do Cloud Storage, incluindo:

Suporte para contas de serviço
As contas de serviço são úteis para interações de servidor para servidor que não exigem envolvimento do usuário final. Para mais informações, consulte Contas de serviço.
Suporte para vários projetos
Vários projetos permitem que você tenha, de fato, muitas instâncias do serviço do Cloud Storage. Isso permite que você separe diferentes funcionalidades ou serviços de seu aplicativo ou empresa conforme necessário. Para mais informações, consulte Como usar projetos.
Autenticação do OAuth 2.0
O OAuth 2.0 depende do SSL para segurança, em vez de exigir que seu aplicativo faça assinaturas criptográficas diretamente, além de ser mais fácil de implementar. Com o OAuth, seu aplicativo pode solicitar acesso a dados associados à Conta do Google de um usuário, e o acesso pode ser definido em vários níveis, incluindo somente leitura, leitura e gravação, e controle total. Para mais informações, consulte Autenticação do OAuth 2.0.

Para migrar totalmente do Amazon S3 para o Cloud Storage, será necessário fazer as alterações a seguir:

  • Altere quaisquer cabeçalhos x-amz-* existentes para cabeçalhos x-goog-* correspondentes.
  • Mude o XML do Access Control List (ACL) da AWS para o XML da ACL do Cloud Storage correspondente (consulte Como especificar ACLs de intervalo e objeto).
  • Defina o cabeçalho x-goog-project-id em suas solicitações. Observe que, em um cenário de migração simples, você escolhe um projeto padrão para todas as solicitações. Isso não é necessário em uma migração completa.
  • Prepare-se para usar a autenticação do OAuth 2.0, conforme descrito em Autenticação do OAuth 2.0. O primeiro passo é registrar o aplicativo (de que você fará solicitações) com o Google. Usar o OAuth 2.0 significa que seu cabeçalho de Authorization ficará assim:

    Authorization: Bearer <oauth2_token>

Controle de acesso em uma migração completa

Nesta seção, mostraremos alguns exemplos de controle de acesso para ajudá-lo a migrar do Amazon S3 para o Cloud Storage. Para uma visão geral do controle de acesso no Cloud Storage, consulte Controle de acesso.

No Cloud Storage, há várias maneiras de aplicar ACLs a intervalos e objetos (consulte Como especificar ACLs de intervalo e objeto). Duas das formas de especificar as ACLs são análogas ao que você faz no Amazon S3:

  • O parâmetro de string de consulta acl para aplicar ACLs para escopos específicos.
  • O cabeçalho de solicitação x-goog-acl permite aplicar ACLs predefinidas, que às vezes são chamadas de "ACLs prontas".

Como usar o parâmetro de string de consulta ACL

Você pode usar o parâmetro de string de consulta acl para uma solicitação do Cloud Storage exatamente da mesma maneira que você usaria para uma solicitação do Amazon S3. O parâmetro acl é usado em conjunto com o método PUT para aplicar as ACLs a um objeto existente, um intervalo existente ou um intervalo que você está criando. Quando você usa o parâmetro de string de consulta acl em uma solicitação PUT, é necessário anexar um documento XML (usando a sintaxe ACL do Cloud Storage) ao corpo de sua solicitação. O documento XML contém as entradas individuais da ACL que você quer aplicar ao intervalo ou objeto.

No exemplo a seguir, mostramos uma solicitação PUT para o Amazon S3 que usa o parâmetro de string de consulta acl. As ACLs são definidas em um documento XML enviado no corpo da solicitação. A solicitação PUT altera as ACLs em um objeto chamado europe/france/paris.jpg que está em um intervalo chamado my-travel-maps. A ACL concede permissão FULL_CONTROL a jane@gmail.com.

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>

A seguir, a mesma solicitação para o 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>

Observe que o Cloud Storage não exige um elemento <Owner/> no documento XML da ACL. Para mais informações, consulte ACLs de objeto padrão.

Também é possível recuperar ACLs de intervalo e de objeto usando o parâmetro de string de consulta acl com o método GET. As ACLs são descritas em um documento XML, que é anexado ao corpo da resposta. Você precisa ter a permissão FULL_CONTROL para aplicar ou recuperar ACLs em um objeto ou intervalo.

Como aplicar ACLs com um cabeçalho de solicitação de extensão

Você pode usar o cabeçalho x-goog-acl em uma solicitação do Cloud Storage para aplicar ACLs predefinidas a grupos e objetos exatamente da mesma maneira que usaria o cabeçalho x-amz-acl em uma solicitação do Amazon S3. Normalmente, você usa o cabeçalho x-goog-acl ( x-amz-acl ) para aplicar uma ACL predefinida a um intervalo ou objeto ao criá-los ou fazer upload deles. As ACLs predefinidas do Cloud Storage são semelhantes às ACLs prontas do Amazon S3, incluindo privadas, públicas de leitura, públicas de leitura e gravação, entre outras. Para uma lista de ACLs predefinidas do Cloud Storage, consulte ACLs predefinidas.

No exemplo a seguir, mostraremos uma solicitação de objetos PUT que aplica a ACL public-read a um objeto chamado europe/france/paris.jpg que está sendo carregado em um intervalo chamado my-travel-maps no 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>

A seguir, a mesma solicitação para o 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>

Também é possível usar o cabeçalho x-goog-acl para aplicar uma ACL predefinida a um intervalo ou objeto existente. Para fazer isso, inclua o parâmetro de string de consulta acl em sua solicitação, mas não inclua um documento XML. A aplicação de uma ACL predefinida a um objeto ou intervalo atual é útil se você quiser mudar de uma ACL predefinida para outra ou se quiser atualizar as ACLs personalizadas para uma ACL predefinida. Por exemplo, a solicitação de objeto PUT a seguir aplica a ACL private predefinida a um objeto denominado europe/france/paris.jpg que está em um intervalo denominado 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>

Para mais informações sobre o gerenciamento de ACLs, consulte Como gerenciar o controle de acesso.

Como migrar de métodos de solicitação do Amazon S3 para métodos de solicitação do Cloud Storage

O Cloud Storage aceita os mesmos métodos de solicitação HTTP padrão para ler e gravar dados nos seus intervalos, conforme a compatibilidade com o Amazon S3. Portanto, a maioria das ferramentas e bibliotecas que você usa atualmente com o Amazon S3 funcionará com o Cloud Storage sem precisar de alterações. O Cloud Storage aceita os métodos de solicitação a seguir:

  • Solicitação de serviço para GET.
  • Solicitações de intervalo, incluindo PUT, GET, DELETE.
  • Solicitações de objeto, incluindo GET, POST, PUT, HEAD e DELETE.

Para mais informações, consulte Métodos de referência da API XML. Lembre-se de que ao enviar solicitações ao Cloud Storage você precisará alterar o corpo da solicitação, quando aplicável, para usar a sintaxe apropriada do Cloud Storage. Por exemplo, ao criar uma configuração de ciclo de vida para um intervalo, use o XML do ciclo de vida do Cloud Storage, que é diferente do XML do ciclo de vida do Amazon S3.

Há algumas diferenças entre a API XML do Cloud Storage e o Amazon S3 e elas estão resumidas abaixo, com alternativas sugeridas para o Cloud Storage:

Funcionalidade do Amazon S3 Funcionalidade da API XML do Cloud Storage
Upload de várias partes
POST /<object-name>, PUT /<object-name>

Na API XML do Cloud Storage, você pode fazer upload de uma série de objetos de componente, realizando um upload separado para cada um deles. Dessa forma, é possível compor os objetos em um único objeto composto.

Observação: embora a API JSON ofereça um recurso de upload de várias partes, esse recurso é usado para enviar metadados junto com dados de objeto. Não é equivalente ao recurso de upload de várias partes do S3.

Parâmetros da string de consulta do intervalo GET/POST:
  • "policy" - como trabalhar com políticas de intervalo do Amazon S3.
  • "website" - como configurar os sites dos intervalos.
  • "tagging" - como pôr tags em intervalos para fins de alocação de custos.
  • "notification" - como notificar eventos de intervalo.
  • "requestPayment" - como configurar quem paga pela solicitação e o download de dados de um intervalo.
Alternativas:
  • "policy" - as ACLs do Cloud Storage, a participação da equipe do projeto e a capacidade de usar vários projetos abordam muitos dos cenários em que as políticas de intervalo são usadas.
  • "website" - use o comando gsutil Web para gerenciar sites ou teste a API JSON (consulte recursos de intervalos).
  • "tagging" - use vários projetos para rastrear diferentes centros de custo. Para mais informações sobre projetos, consulte Como gerenciar projetos.
  • "notification" - use o gsutil ou as Notificações Pub/Sub da API JSON.
  • "requestPayment" - use vários projetos com diferentes perfis de faturamento para gerenciar quem paga por solicitações e dados de download de um intervalo. Para mais informações sobre como configurar o faturamento, consulte Faturamento na documentação da Ajuda do Console de APIs do Google.
Exclusão de vários objetos.
POST /?delete

Use o comando rm do gsutil para remover vários objetos com facilidade. O comando rm aceita a opção "-m" para executar exclusões paralelas (multithreaded/multiprocessamento).

Como alternativa, a API JSON aceita o envio de solicitações em lote para reduzir o número de conexões HTTP feitas por seu cliente.

Como migrar de cabeçalhos do Amazon S3 para cabeçalhos do Cloud Storage

O Cloud Storage usa vários cabeçalhos HTTP padrão, além de vários cabeçalhos HTTP personalizados (extensão). Se você estiver fazendo a transição do Amazon S3 para o Cloud Storage, poderá converter seus cabeçalhos personalizados do Amazon S3 para o cabeçalho personalizado equivalente do Cloud Storage ou para uma funcionalidade semelhante, conforme mostrado na tabela abaixo.

Cabeçalho do Amazon S3 Cabeçalho do 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 com um valor de ACL predefinido.
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 Não é obrigatório. Todos os dados do Cloud Storage são criptografados automaticamente antes de serem gravados no disco. Para mais informações, consulte Criptografia.
x-amz-storage-class Você pode especificar a classe de armazenamento ao criar um intervalo. Para mais informações, consulte Classes de armazenamento.
x-amz-mfa Use a autenticação do OAuth 2.0.
x-amz-website-redirect-location, x-amz-copy-source-range n/a

Grupos de discussão e suporte para compatibilidade da API XML com o Amazon S3

O grupo gs-discussion do Cloud Storage, que anteriormente aceitava problemas de interoperabilidade e migração da API XML, está em modo de arquivo. Agora, o fórum de discussão pode ser acessado no Stack Overflow usando a tag google-cloud-storage. Consulte a página Recursos e suporte para mais informações sobre fóruns de discussão e assinatura de anúncios.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Precisa de ajuda? Acesse nossa página de suporte.