Migra de Amazon S3 a Google Cloud Storage

En esta página, se describe cómo migrar de Amazon Simple Storage Service (Amazon S3) a Cloud Storage para los usuarios que envían solicitudes mediante el uso de una API. Si actualmente no usas Amazon S3 y deseas enviar solicitudes mediante el uso de la API de Cloud Storage, comienza aquí: Descripción general de la API XML.

Si eres nuevo en Cloud Storage y no vas a usar la API directamente, considera usar Google Cloud Platform Console para configurar y administrar las transferencias. Google Cloud Platform Console proporciona una interfaz gráfica para Cloud Storage que te permite realizar muchas de tus tareas de almacenamiento con solo un navegador, incluida la migración de tus datos de Amazon S3 a Cloud Storage.

Descripción general de la migración

Si eres un usuario de Amazon S3, puedes migrar fácilmente tus aplicaciones que usan Amazon S3 para usar Cloud Storage. Tienes dos opciones de migración:

Migración simple

Esta es la forma más fácil de comenzar con Cloud Storage si vienes de Amazon S3 porque requiere solo unos cambios simples en las herramientas y bibliotecas que actualmente usas con Amazon S3. Para obtener más información, consulta Migración simple.

Si bien una migración simple te permite ponerte en marcha rápidamente con Cloud Storage, no te permite usar todas las funciones de Cloud Storage. Para aprovechar al máximo Cloud Storage, sigue los pasos de una migración completa.

Migración completa

Una migración completa de Amazon S3 a Cloud Storage necesita un poco más de pasos adicionales que una migración simple, pero la ventaja es que puedes usar todas las características de Cloud Storage, incluida la asistencia en cuentas de servicio, varios proyectos y OAuth 2.0 para la autenticación. Para obtener más información, consulta Migración completa.

Migración simple

En una migración simple de Amazon S3 a Cloud Storage, puedes usar tus herramientas y bibliotecas existentes para generar solicitudes REST autenticadas a Amazon S3, y así enviar también solicitudes autenticadas a Cloud Storage. Los cambios que necesitas realizar en tus herramientas y bibliotecas existentes se describen en esta sección.

Para configurar una migración simple, haz lo siguiente:

Listo. En este punto, puedes comenzar a usar tus herramientas y bibliotecas existentes para enviar solicitudes de código de autenticación de mensaje en clave hash (HMAC) a Cloud Storage.

Cuando usas la API de XML de Cloud Storage en una migración simple y especificas el identificador de firma AWS en el encabezado Authorization permites que Cloud Storage espere a que haya encabezados x-amz-* y sintaxis XML de LCA en Amazon S3 en tu solicitud.

Configura un proyecto predeterminado

Para usar Cloud Storage en una situación de migración simple, debes elegir un proyecto predeterminado. Cuando eliges un proyecto predeterminado, le estás diciendo a Cloud Storage el proyecto que debe usar para operaciones como el servicio GET o el depósito PUT.

Sigue estos pasos para establecer un proyecto predeterminado:

  1. Abre la pagina Configuración de Cloud Storage en Google Cloud Platform Console.
  2. Selecciona Interoperabilidad.
  3. Haz clic en Hacer este ID de Proyecto mi proyecto predeterminado.

    Si el proyecto ya es el proyecto predeterminado, verás que el ID de Proyecto es tu proyecto predeterminado.

Este proyecto es ahora tu proyecto predeterminado. Puedes cambiar tu proyecto predeterminado en cualquier momento, solo selecciona un proyecto diferente y habilita el acceso interoperable para él.

Administra claves de desarrollador para una migración simple

Para usar la API de XML de Cloud Storage en una situación de migración simple, debes usar el código de autenticación de mensaje con clave hash (HMAC) con claves de desarrollador de Cloud Storage. Las claves de desarrollador consisten en una clave de acceso y un secreto. Una clave de acceso es una string alfanumérica de 24 caracteres, que está vinculada a tu Cuenta de Google. Todas las solicitudes de Cloud Storage autenticadas, excepto aquellas que usan autenticación basada en cookies, deben usar una clave de acceso en la solicitud para que el sistema de Cloud Storage sepa quién realiza la solicitud. El siguiente es un ejemplo de una clave de acceso:

GOOGTS7C7FUP3AIRVJTE2BCD

Un secreto es una string codificada en Base 64 de 40 caracteres que está vinculado a una clave de acceso específica. Un secreto es una clave previamente compartida que solo tú y el sistema de Cloud Storage conocen. Debes usar tu secreto para firmar todas las solicitudes como parte del proceso de autenticación. El siguiente es un ejemplo de un secreto:

bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ

Sigue estos pasos para generar una clave de desarrollador:

  1. Abre la pagina Configuración de Cloud Storage en Google Cloud Platform Console.
  2. Selecciona Interoperabilidad.
  3. Si no has configurado la interoperabilidad anteriormente, haz clic en Habilita acceso de interoperabilidad.
  4. Haz clic en Crear clave nueva.

Sugerencias de seguridad para trabajar con claves de desarrollador

Puedes crear hasta cinco claves de desarrollador. Esto es útil si estás trabajando en varios proyectos diferentes y deseas usar diferentes claves de desarrollador para cada proyecto.

También puedes usar la herramienta de administración de claves para borrar las claves de desarrollador y crear claves de desarrollador nuevas. Es posible que desees hacer esto si crees que otra persona está usando tus claves de desarrollador o si necesitas cambiar tus claves como parte de una rotación de claves, lo cual es una práctica de seguridad recomendada. Si tienes claves de desarrollador y deseas crear claves de desarrollador nuevas, te recomendamos que primero actualices tu código con las claves de desarrollador nuevas antes de borrar las claves antiguas. Cuando borras las claves de desarrollador, estas se vuelven inmediatamente no válidas y no son recuperables.

Autenticación en una situación de migración simple

Encabezado de autorización

Para las operaciones en una situación de migración simple que requiere autenticación, incluirás un encabezado de solicitud de Authorization igual que con las solicitudes para Amazon S3. La sintaxis del encabezado de Authorization para una solicitud de Amazon S3:

Authorization: AWS AWS-ACCESS-KEY:signature

En una situación de migración simple, solo cambias el encabezado para usar tu clave de acceso de Google Developer:

Authorization: AWS GOOG-ACCESS-KEY:signature

Las partes del encabezado de Authorization son:

Identificador de firma
El identificador de firma identifica el algoritmo de firma y la versión que estás usando. El uso de AWS indica que tienes la intención de enviar encabezados x-amz-*.
Clave de acceso
La clave de acceso identifica la entidad que está realizando y firmando la solicitud. En una migración simple, reemplaza el ID de la clave de acceso de Amazon Web Service (AWS) que usas para acceder a Amazon S3 con tu clave de acceso de desarrollador de Google. Tu clave de acceso de desarrollador de Google comienza con "GOOG".
Firma

La firma es un hash criptográfico con clave de varios encabezados de solicitud. La firma se crea mediante el uso de HMAC-SHA1 como función hash y tu secreto como clave criptográfica. El resumen resultante es codificado en Base64. Cuando Cloud Storage recibe tu solicitud firmada, usa la clave de acceso para buscar tu secreto y verificar que hayas creado la firma. Para obtener más información sobre cómo obtener un acceso y una clave secreta, consulta Administra claves de desarrollador para el acceso en una situación de migración simple.

En una migración simple, reemplaza la clave de acceso secreta de AWS con tu clave de desarrollador de Google como la clave criptográfica.

Cálculo de autenticación

En esta sección, se describe el proceso de autenticación de una solicitud de API de XML en una situación de migración simple. Si bien esta sección se puede usar para desarrollar tu propio código a fin de firmar solicitudes, está destinada principalmente a ser una revisión si ya tienes herramientas o bibliotecas que firman tus solicitudes a Amazon S3. En este caso, continuarás con el uso de estas herramientas para acceder a Cloud Storage con la API de XML con los cambios que se muestran aquí.

Este método de autenticación proporciona identidad y autenticación sólida sin revelar tu secreto. Proporcionar identidad y autenticación en cada solicitud ayuda a garantizar que cada solicitud de Cloud Storage se procese bajo una cuenta de usuario específica y con la autoridad de esa cuenta de usuario. Esto es posible porque solo tú y el sistema de Cloud Storage conocen tu secreto. Cuando realizas una solicitud, el sistema de Cloud Storage usa tu secreto para calcular la misma firma en la solicitud que calculaste cuando realizaste la solicitud. Si las firmas coinciden, entonces el sistema de Cloud Storage sabe que solo tú pudiste haber realizado la solicitud.

El siguiente pseudocódigo muestra cómo crear la firma para el encabezado de autorización:

Signature = Base64-Encoding-Of(HMAC-SHA1(YourGoogleStorageSecretKey, MessageToBeSigned))

Para crear la firma, usa una función de hash criptográfica conocida como HMAC-SHA1. HMAC-SHA1 es un código de autenticación de mensaje (MAC) basado en hash y se describe en RFC 2104. Requiere dos parámetros de entrada, ambos codificados en UTF-8: una clave y un mensaje. La clave es tu secreto de Cloud Storage y el mensaje debe construirse si concatenas encabezados HTTP específicos en un orden específico. El siguiente pseudocódigo muestra cómo construir el mensaje:

MessageToBeSigned = UTF-8-Encoding-Of(CanonicalHeaders + CanonicalExtensionHeaders + CanonicalResource)

Cada una de las entidades canónicas que componen el mensaje representa una concatenación estrictamente ordenada y de formato estricto de varios encabezados y recursos. Las siguientes secciones describen cómo construir cada una de estas entidades.

CanonicalHeaders

Construye la parte de CanonicalHeaders de MessageToBeSigned, para ello, concatena varios valores de encabezado y agrega una línea nueva (U + 000A) después de cada valor de encabezado. La siguiente notación de pseudocódigo te muestra cómo hacerlo (las líneas nuevas están representadas por \n ):

CanonicalHeaders = HTTP-Verb + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n"

No incluyas los nombres de encabezado en la string concatenada, incluye solo los valores de encabezado. Si no existe un encabezado requerido en una solicitud, sustituye una string vacía por el valor del encabezado y asegúrate de incluir la línea nueva después de la cadena vacía. Además, el encabezado de Date es obligatorio para todas las solicitudes autenticadas, por lo que este campo se debe propagar con un sello de fecha y hora válido. El sello de fecha y hora debe estar dentro de los 15 minutos posteriores a la fecha en que Cloud Storage recibe tu solicitud.

También puedes usar las extensiones de encabezado de x-amz-date o x-goog-date para especificar el sello de fecha y hora. Si usas el encabezado de extensión de fecha, Cloud Storage ignora el encabezado de Date en tu solicitud. En este caso, sustituye una string vacía por el encabezado de Date.

CanonicalExtensionHeaders

Tu construyes la parte CanonicalExtensionHeaders cuando concatenas todos los encabezados de extensión (personalizados) que comienzan con x-amz- o x-goog-. Sin embargo, no puedes realizar una concatenación simple. Debes concatenar los encabezados, para ello usa el siguiente proceso:

  1. Haz todos los nombres de encabezados personalizados en minúsculas.
  2. Ordena todos los encabezados personalizados lexicográficamente por nombre de encabezado.
  3. Borra los nombres de encabezados duplicados y crea un nombre de encabezado con una lista de valores separados por comas. Asegúrate de que no haya espacios en blanco entre los valores y de que el orden de la lista separada por comas coincida con el orden en que aparecen los encabezados en tu solicitud. Para obtener más información, consulta RFC 7230, sección 3.2.
  4. Reemplaza cualquier espacio en blanco plegable o salto de línea (CRLF o LF) con un solo espacio. Para obtener más información sobre el plegado de espacios en blanco, consulta RFC 2822, sección 2.2.3.
  5. Quita los espacios en blanco alrededor de los dos puntos que aparecen después del nombre del encabezado.
  6. Agrega un salto de línea (U + 000A) a cada encabezado personalizado.
  7. Concatena todos los encabezados personalizados.

Es importante tener en cuenta que usas tanto el nombre del encabezado como el valor del encabezado cuando construyes la parte del mensaje de CanonicalExtensionHeaders. Esto es diferente a la parte del mensaje de CanonicalHeaders, que solo usaba valores de encabezado.

CanonicalResource

Construyes la parte de CanonicalResource del mensaje cuando concatenas la ruta de acceso a los recursos (depósito, objeto y subrecurso) sobre el que actúa la solicitud. Para ello, puedes usar el siguiente proceso:

  1. Comienza con una string vacía.
  2. Si el nombre del depósito aparece en el encabezado del host, agrega una barra (/) y el nombre del depósito al string (por ejemplo, /travel-maps). Si el nombre del depósito aparece en la parte de la ruta de acceso de la solicitud HTTP, no hagas nada.
  3. Agrega la porción de ruta de acceso de la solicitud HTTP a la string y excluye cualquier parámetro de string de consulta. Por ejemplo, si la ruta de acceso es /europe/france/paris.jpg?acl y ya agregaste los mapas de viaje al depósito de la string, entonces debes agregar /europe/france/paris.jpg a la string.
  4. Si la solicitud se aplica a un subrecurso, como ?acl, agrega este subrecurso a la string, incluido el signo de interrogación.

Copia la ruta de acceso de solicitud HTTP literalmente, es decir, debes incluir toda la codificación de URL (signos de porcentaje) en la string que crees. Incluye solo los parámetros de la string de consulta que designan los subrecursos (como acl). No debes incluir parámetros de string de consulta, como ?prefix, ?max-keys, ?marker y ?delimiter.

Los siguientes ejemplos muestran cómo se ve el mensaje firmado para diferentes tipos de solicitudes.

Solicitud de autenticación de muestra

Los siguientes ejemplos suben un objeto llamado /europe/france/paris.jpg a un depósito llamado my-travel-maps, aplican la LCA predeterminada public-read, y definen un encabezado de metadatos personalizado para los revisores. A continuación, se muestra la solicitud a un depósito en Amazon S3:

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Tue, 05 Nov 2013 23:46:19 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
x-amz-meta-reviewer: joe,jane
Authorization: AWS AWS-ACCESS-KEY:Signature

A continuación, se muestra la solicitud de un depósito en Cloud Storage:

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Tue, 05 Nov 2013 23:47:01 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
x-amz-meta-reviewer: joe,jane
Authorization: AWS GOOG-ACCESS-KEY:Signature

A continuación, se muestra el mensaje correspondiente que se firmará para la solicitud de Cloud Storage, MessageToBeSigned:

PUT\n
\n
image/jpg\n
Tue, 05 Nov 2013 23:47:01 GMT\n
x-amz-acl:public-read\n
x-amz-meta-reviewer:joe,jane\n
/my-travel-maps/europe/france/paris.jpg

Esta solicitud no proporcionó un encabezado Content-MD5, por lo que se muestra una string vacía en el mensaje (segunda línea).

Control de acceso en una situación de migración simple

Para admitir migraciones simples, Cloud Storage acepta las LCA producidas por Amazon S3. En una situación de migración simple, usarás AWS como tu identificador de firma, que le indica a Cloud Storage que espere la sintaxis de la LCA mediante el uso de la sintaxis de la LCA de XML de Amazon S3. Debes asegurarte de que las LCA de Amazon S3 que usas se mapeen con el modelo de LCA de Cloud Storage. Por ejemplo, si tus herramientas y bibliotecas usan la sintaxis de la LCA de Amazon S3 para otorgar permiso de WRITE a un depósito, entonces también deben otorgar permiso de READ al depósito porque los permisos de Cloud Storage son concéntricos. No es necesario que especifiques ambos permisos de WRITE y READ cuando otorgas el permiso de WRITE mediante la sintaxis de Cloud Storage.

Cloud Storage admite la sintaxis de la LCA de Amazon S3 en las siguientes situaciones:

  • En una solicitud a Cloud Storage para recuperar las LCA (por ejemplo, una solicitud de objeto GET o depósito GET), Cloud Storage muestra la sintaxis de la LCA de Amazon S3.
  • En una solicitud a Cloud Storage para aplicar las LCA (por ejemplo, una solicitud de objeto PUT o depósito PUT), Cloud Storage espera recibir la sintaxis de la LCA de Amazon S3.

El encabezado de Authorization en una situación de migración simple usará AWS para el identificador de la firma, pero con tu clave de acceso de Google.

Authorization: AWS GOOG-ACCESS-KEY:signature

El siguiente ejemplo muestra una solicitud GET a Cloud Storage a fin de mostrar las LCA para un objeto.

GET europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Thu, 07 Nov 2013 01:04:05 GMT
Content-Type: application/xml
Authorization: AWS GOOG-ACCESS-KEY:Sku4/Nc1q4yJ6+7q7Sk3PFAAelE=

La respuesta a la solicitud incluye la LCA mediante el uso de la sintaxis de la LCA de 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>

El siguiente ejemplo muestra una solicitud PUT a Cloud Storage para establecer las LCA de un objeto. El ejemplo muestra un cuerpo de solicitud con la sintaxis de la LCA de Amazon S3.

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Thu, 07 Nov 2013 01:55:16 GMT
Content-Type: application/xml
Content-Length: 337
Authorization: AWS GOOG-ACCESS-KEY:Ugm1lh6Bb+nAfNVa5ljUgfXYMfQ=

<?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>

Finalmente, en una situación de migración simple, también puedes usar el identificador de firma GOOG1 en el encabezado de Authorization. En este caso, debes usar la sintaxis de la LCA de Cloud Storage y asegurarte de que todos tus encabezados sean encabezados de Google, x-goog-*. Si bien esto es posible, te recomendamos que cambies a una migración completa como se describe a continuación para obtener todos los beneficios de Cloud Storage.

Migración completa

Una migración completa de Amazon S3 a Cloud Storage te permite aprovechar todas las funciones de Cloud Storage, que incluyen lo siguiente:

Asistencia para cuentas de servicio
Las cuentas de servicio son útiles para las interacciones de servidor a servidor que no requieren la participación del usuario final. Para obtener más información, consulta Cuentas de servicio.
Asistencia para varios proyectos
Varios proyectos te permiten tener, en efecto, muchas instancias del servicio de Cloud Storage. Esto te permite separar diferentes funcionalidades o servicios de tu aplicación o negocio según sea necesario. Para obtener más información, consulta Usa proyectos.
Autenticación OAuth 2.0
OAuth 2.0 se basa en SSL para la seguridad en lugar de requerir que tu aplicación realice una firma criptográfica directamente y es más fácil de implementar. Con OAuth, tu aplicación puede solicitar acceso a los datos asociados con la Cuenta de Google de un usuario, y el acceso puede alcanzar varios niveles, incluidos solo lectura, lectura y escritura y control total. Para obtener más información, consulta Autenticación de OAuth 2.0.

Para migrar completamente de Amazon S3 a Cloud Storage, deberás realizar los siguientes cambios:

  • Cambia cualquier encabezado x-amz-* existente al encabezado correspondiente x-goog-*.
  • Cambia la lista de control de acceso AWS (LCA) de XML a la LCA de XML de Cloud Storage (consulta Especifica el depósito y el objecto de la LCA).
  • Consulta el encabezado x-goog-project-id en tus solicitudes. Ten en cuenta que en una situación de migración simple, elegiste un proyecto predeterminado para todas las solicitudes. Esto no es necesario en una migración completa.
  • Prepárate para usar la autenticación OAuth 2.0 como se describe en Autenticación de OAuth 2.0. El primer paso es registrar tu aplicación (desde donde emitirás las solicitudes) con Google. Usar OAuth 2.0 significa que tu encabezado de Authorization se verá así:

    Authorization: Bearer <oauth2_token>

Control de acceso en una migración completa

En esta sección, se muestran algunos ejemplos de control de acceso para ayudarte a migrar de Amazon S3 a Cloud Storage. Para obtener una descripción general del control de acceso en Cloud Storage, consulta Control de acceso.

En Cloud Storage, hay varias formas de aplicar las LCA a depósitos y objetos (consulta Especifica depósito y objeto de LCA). Dos de las formas en que especificas las LCA son analógicas, como se hace en Amazon S3 de la siguiente manera:

  • El parámetro de string de consulta acl para aplicar las LCA en ámbitos específicos.
  • El encabezado de solicitud x-goog-acl te permite aplicar las LCA predefinidas, que a veces se conocen como LCA conservadas.

Usa el parámetro de string de consulta la LCA

Puedes usar el parámetro de string de consulta acl en una solicitud de Cloud Storage exactamente de la misma manera que lo usarías para una solicitud de Amazon S3. El parámetro acl se usa junto con el método PUT a fin de aplicar las LCA a lo siguiente: Un objeto existente, un depósito existente o un depósito que estás creando. Cuando usas el parámetro de string de consulta acl en una solicitud PUT, debes adjuntar un documento XML (usa la sintaxis de la LCA de Cloud Storage) al cuerpo de tu solicitud. El documento XML contiene las entradas individuales de LCA que deseas aplicar al objeto o depósito.

El siguiente ejemplo muestra una solicitud PUT a Amazon S3 que usa el parámetro de string de consulta acl. Las LCA se definen en un documento XML enviado en el cuerpo de la solicitud. La solicitud PUT cambia las LCA en un objeto llamado europe/france/paris.jpg que se encuentra en un depósito llamado my-travel-maps. La LCA otorga permiso de 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: AWS AWS-ACCESS-KEY:eNB6IUnqzsVAZ69TZZ5yFMQ5SvE=

<?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 continuación, se muestra la misma solicitud en 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>

Ten en cuenta que Cloud Storage no requiere un elemento <Owner/> en el documento XML de la LCA. Para obtener más información, consulta LCA de objetos predeterminados.

También puedes recuperar las LCA de depósito y objeto si usas el parámetro de string de consulta acl con el método GET. Las LCA se describen en un documento XML, que se adjunta al cuerpo de la respuesta. Debes tener el permiso FULL_CONTROL para aplicar o recuperar las LCA en un objeto o depósito.

Aplica las LCA con un encabezado de solicitud de extensión

Puedes usar el encabezado x-goog-acl en una solicitud de Cloud Storage para aplicar las LCA predeterminadas a depósitos y objetos exactamente de la misma manera que usarías el encabezado x-amz-acl en una solicitud de Amazon S3. Normalmente se usa el encabezado x-goog-acl (x-amz-acl) para aplicar una LCA predeterminada a un objeto o depósito cuando se crea o sube el objeto o depósito. Las LCA predeterminadas de Cloud Storage son similares a las LCA conservadas de Amazon S3, incluidas las privadas, las de lectura pública, las de lectura y escritura públicas y otras Para obtener una lista de las LCA predeterminadas de Cloud Storage, consulta LCA predeterminadas.

El siguiente ejemplo muestra una solicitud de objeto PUT que aplica la LCA de public-read a un objeto llamado europe/france/paris.jpg que se está subiendo al depósito llamado my-travel-maps en 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: AWS AWS-ACCESS-KEY:o8PRLyrTxsMEznHzgQvTt2TnWTI=

<888814 bytes in entity body>

A continuación, se muestra la misma solicitud en 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>

También puedes usar el encabezado x-goog-acl para aplicar una LCA predeterminada a un objeto o depósito existente. Para hacer esto incluye el parámetro de string de consulta acl en tu solicitud, pero no incluyas un documento XML en ella. La aplicación de una LCA predefinida a un objeto o depósito existente es útil si deseas cambiar de una LCA predeterminada a otra, o si deseas actualizar las LCA personalizadas a unas LCA predeterminadas. Por ejemplo, la siguiente solicitud de Objeto PUT aplica la LCA predeterminada private a un objeto llamado europe/france/paris.jpg que está en un depósito llamado 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 obtener más información sobre la administración de LCA, consulta Administra el control de acceso.

Migración de Amazon S3 a los métodos de solicitud de Cloud Storage

Cloud Storage admite los mismos métodos de solicitud HTTP estándar para leer y escribir datos en tus depósitos que los que admite Amazon S3. Por lo tanto, la mayoría de las herramientas y bibliotecas que usas actualmente con Amazon S3, funcionarán igual que con Cloud Storage. Cloud Storage admite los siguientes métodos de solicitud:

  • Solicitud de servicio para GET
  • Solicitudes de depósito, que incluyen PUT, GET, DELETE
  • Solicitudes de objetos, incluidos GET, POST, PUT, HEAD y DELETE

Para obtener más información, consulta Métodos de referencia de la API de XML. Ten en cuenta que cuando envíes solicitudes a Cloud Storage, deberás cambiar el cuerpo de la solicitud, cuando sea aplicable, para usar la sintaxis de Cloud Storage adecuada. Por ejemplo, cuando creas una configuración de ciclo de vida para un depósito, usa el XML de ciclo de vida de Cloud Storage, que es diferente al XML de ciclo de vida de Amazon S3.

Existen algunas diferencias entre la API de XML de Cloud Storage y Amazon S3 que se resumen a continuación con las alternativas de Cloud Storage sugeridas:

Funcionalidad de Amazon S3 Funcionalidad de la API de XML de Cloud Storage
Carga multiparte.
POST /<object-name>, PUT /<object-name>

En la API de XML de Cloud Storage, puedes subir una serie de objetos componentes, realiza una carga separada para cada componente. Luego puedes redactar los objetos en un solo objeto compuesto.

Nota: Si bien API de JSON ofrece una función de carga multiparte, esta función se usa para enviar metadatos junto con datos de objetos. No es equivalente a la función de carga multiparte de S3.

Parámetros de la string de consulta de los depósitos GET / POST:
  • "política": Trabajar con las políticas de depósito de Amazon S3.
  • "website": Configuración de sitios web de depósito.
  • "etiquetado": Etiquetado de depósitos para fines de asignación de costos.
  • "notificación": Notificación de eventos de depósito.
  • "requestPayment": Configuración de quién paga la solicitud y la descarga de datos desde un depósito.
Alternativas:
  • "política": Las LCA de Cloud Storage, la membresía del equipo del proyecto y la capacidad de usar múltiples proyectos abordan muchas de las situaciones en los que se usan las políticas de depósito.
  • "website": Usa el comando web gsutil para administrar sitios web o prueba la API de JSON (consulta recursos de depósitos).
  • "etiquetado": Usa varios proyectos para hacer un seguimiento de los diferentes centros de costos. Para obtener más información sobre los proyectos, consulta Administra proyectos.
  • "notificación": Usa gsutil o la API de JSON Cloud Pub/Sub Notifications.
  • "requestPayment": Usa varios proyectos con diferentes perfiles de facturación para administrar quién paga las solicitudes y los datos descargados de un depósito. Para obtener más información sobre la configuración de la facturación, consulta Facturación en la documentación de la ayuda de Console de las API de Google
Borra varios objetos.
POST /?borrar

Usa el comando gsutil rm para quitar fácilmente múltiples objetos. El comando rm admite la opción "-m" para hacer borrados paralelos (multiproceso o multiprocesamiento).

Como alternativa, la API de JSON admite el envío de solicitudes por lotes para reducir la cantidad de conexiones HTTP que realiza tu cliente.

Migración de Amazon S3 a los encabezados de Cloud Storage

Cloud Storage usa varios encabezados HTTP estándar, así como varios encabezados HTTP personalizados (extensión). Si estás haciendo la transición de Amazon S3 a Cloud Storage, puedes convertir tus encabezados personalizados de Amazon S3 en el encabezado personalizado al equivalente de Cloud Storage o una funcionalidad similar, como se muestra en la siguiente tabla.

Encabezado de Amazon S3 Encabezado de 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 con un valor de la LCA predeterminado.
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 No requerido. Cloud Storage encripta automáticamente todos los datos antes de que se escriban en el disco. Para obtener más información, consulta Encriptación.
x-amz-storage-class Puedes especificar la clase de almacenamiento cuando creas un depósito. Para obtener más información, consulta Clases de almacenamiento.
x-amz-mfa Usa la autenticación OAuth 2.0.
x-amz-website-redirect-location, x-amz-copy-source-range No corresponde

Grupos de discusión y asistencia para compatibilidad de la API de XML con Amazon S3

El grupo gs-discussion de Cloud Storage que anteriormente era compatible con interoperabilidad de API de XML y problemas de migración, se encuentra en modo de archivo. Ahora se puede acceder al foro de discusión en Stack Overflow con la etiqueta google-cloud-storage. Consulta la página Recursos y asistencia para obtener más información sobre los foros de discusión y cómo suscribirte a los anuncios.

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

¿Necesitas ayuda? Visita nuestra página de asistencia.