Concesión de acceso entre cuentas - AWS Glue

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Concesión de acceso entre cuentas

Al conceder acceso a recursos de Data Catalog entre cuentas, los trabajos de extracción, transformación y carga (ETL) pueden consultar y combinar datos de diferentes cuentas.

Métodos para conceder acceso entre cuentas en AWS Glue

Puede conceder acceso a sus datos a AWS cuentas externas mediante AWS Glue métodos o mediante concesiones AWS Lake Formation entre cuentas. Los AWS Glue métodos utilizan políticas AWS Identity and Access Management (IAM) para lograr un control de acceso detallado. Lake Formation utiliza un modelo de permisos GRANT/REVOKE similares a los comandos de GRANT/REVOKE en un sistema de base de datos relacional.

En esta sección, se describe el uso de los métodos de AWS Glue. Para obtener más información sobre cómo utilizar concesiones entre cuentas de Lake Formation, consulte Concesión de permisos de Lake Formation en la Guía para desarrolladores de AWS Lake Formation .

Hay dos métodos de AWS Glue para conceder acceso entre cuentas a un recurso:

  • Uso de una política de recursos de Data Catalog

  • Uso de un rol de IAM

Concesión de acceso entre cuentas con una política de recursos

Los siguientes son los pasos generales para conceder acceso entre cuentas mediante una política de recursos de Data Catalog:

  1. Un administrador (u otra identidad autorizada) en la cuenta A asocia una política de recursos a Data Catalog en la cuenta A. Esta política concede a la cuenta B permisos específicos entre cuentas para realizar operaciones en un recurso en el catálogo de la cuenta A.

  2. Un administrador de la cuenta B asocia una política de IAM a una identidad de IAM en la cuenta B que delega los permisos recibidos de la cuenta A.

    La identidad de la cuenta B ahora tiene acceso al recurso especificado en la cuenta A.

    La identidad necesita permiso de ambos, el propietario de los recursos (cuenta A) y su cuenta principal (cuenta B), para poder obtener acceso al recurso.

Conceder acceso entre cuentas mediante un rol de IAM

Los siguientes son los pasos generales para conceder acceso entre cuentas mediante un rol de IAM:

  1. Un administrador (u otra identidad autorizada) en la cuenta que posee el recurso (cuenta A) crea un rol de IAM.

  2. El administrador de la cuenta A asocia una política al rol que concede permisos entre cuentas para acceder al recurso en cuestión.

  3. El administrador de la cuenta A asocia al rol una política de confianza que identifica una identidad de IAM en una cuenta diferente (cuenta B) como la entidad principal que puede asumir el rol.

    El principal de la política de confianza también puede ser el director de un AWS servicio si se quiere conceder un permiso de AWS servicio para que asuma esa función.

  4. Un administrador de la cuenta B ahora delega los permisos a una o varias identidades de IAM de la cuenta B para que puedan asumir ese rol. De esta forma, ofrece a las identidades de la cuenta B acceso al recurso de la cuenta A.

Para obtener más información sobre el uso de IAM para delegar permisos, consulte Access management (Administración de accesos) en la Guía del usuario de IAM. Para obtener más información acerca de los usuarios, los grupos, los roles y los permisos, consulte Identidades (usuarios, grupos y roles) en la Guía del usuario de IAM.

Si desea obtener una comparación de estos dos enfoques, consulte Cómo los roles de IAM difieren de las políticas basadas en recursos en la Guía del usuario de IAM. AWS Glue es compatible con ambas opciones, con la restricción de que una política de recursos puede conceder acceso únicamente a los recursos de Catálogo de datos.

Por ejemplo, para conceder al rol Dev de la cuenta B acceso a la base de datos db1 en la cuenta A, asocie la siguiente política de recursos al catálogo de la cuenta A.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetDatabase" ], "Principal": {"AWS": [ "arn:aws:iam::account-B-id:role/Dev" ]}, "Resource": [ "arn:aws:glue:us-east-1:account-A-id:catalog", "arn:aws:glue:us-east-1:account-A-id:database/db1" ] } ] }

Además, la cuenta B tendría que asociar la siguiente política de IAM al rol Dev para obtener acceso a db1 en la cuenta A.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetDatabase" ], "Resource": [ "arn:aws:glue:us-east-1:account-A-id:catalog", "arn:aws:glue:us-east-1:account-A-id:database/db1" ] } ] }

Agregar o actualizar la política de recursos de Data Catalog

Puede agregar o actualizar la política de recursos del catálogo de AWS Glue datos mediante la consola, la API o AWS Command Line Interface (AWS CLI).

importante

Si ya ha otorgado permisos entre cuentas desde su cuenta con AWS Lake Formation, agregar o actualizar la política de recursos de Data Catalog requiere un paso adicional. Para obtener más información, consulte Administrar los permisos entre cuentas utilizando AWS Glue y Lake Formation en la Guía para desarrolladores de AWS Lake Formation .

Para determinar si existen concesiones entre cuentas de Lake Formation, utilice la operación de API glue:GetResourcePolicies o la AWS CLI. Si glue:GetResourcePolicies devuelve una política que no sea de Catálogo de datos, se cuenta con concesiones de Lake Formation. Para obtener más información, consulte Ver todas las concesiones entre cuentas mediante la operación de la GetResourcePolicies API en la Guía para AWS Lake Formation desarrolladores.

Agregar o actualizar la política de recursos de Data Catalog (consola)
  1. Abra la consola de AWS Glue en https://console.aws.amazon.com/glue/.

    Inicie sesión como usuario administrativo AWS Identity and Access Management (IAM) que tiene el glue:PutResourcePolicy permiso.

  2. En el panel de navegación, seleccione Configuración.

  3. En la página Data catalog settings (Configuración de Data Catalog), en Permissions (Permisos), pegue una política de recursos en el área de texto. A continuación, elija Guardar.

    Si la consola muestra una alerta que indica que los permisos de la política se agregarán a los permisos concedidos mediante Lake Formation, elija Proceed (Proceder).

Agregar o actualizar la política de recursos de Data Catalog (AWS CLI)

Realización de una llamada a la API entre cuentas

Todas las operaciones de AWS Glue Data Catalog tienen un campo CatalogId. Si se han concedido los permisos necesarios para permitir el acceso entre cuentas, un intermediario puede realizar llamadas a la API de Data Catalog entre cuentas. El intermediario realiza este procedimiento pasando el ID de cuenta de AWS de destino en CatalogId de manera que acceda al recurso en esa cuenta de destino.

Si no se proporciona ningún valor CatalogId, AWS Glue utiliza el propio ID de cuenta del intermediario de forma predeterminada y la llamada no será entre cuentas.

Realización de una llamada a ETL entre cuentas

Algunas API AWS Glue PySpark y las API de Scala tienen un campo de ID de catálogo. Si se han concedido todos los permisos necesarios para permitir el acceso entre cuentas, un trabajo de ETL puede realizar operaciones de API en todas las cuentas PySpark y Scala llama a ellas pasando el identificador de AWS cuenta de destino en el campo de ID del catálogo para acceder a los recursos del catálogo de datos de una cuenta de destino.

Si no se proporciona ningún valor de ID de catálogo, AWS Glue utiliza el propio ID de cuenta del intermediario de forma predeterminada y la llamada no será entre cuentas.

Para ver PySpark las API compatiblescatalog_id, consulte. Clase GlueContext Para API de Scala que admiten catalogId, consulte API GlueContext Scala de AWS Glue.

El siguiente ejemplo muestra los permisos que requiere al beneficiario para ejecutar un trabajo de ETL. En este ejemplo, grantee-account-ides catalog-id el cliente que ejecuta el trabajo y grantor-account-ides el propietario del recurso. En este ejemplo se concede permiso a todos los recursos de catálogo de la cuenta del concedente. Para limitar el alcance de recursos concedidos, puede proporcionar ARN específicas para el catálogo, la base de datos, la tabla y la conexión.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetConnection", "glue:GetDatabase", "glue:GetTable", "glue:GetPartition" ], "Principal": {"AWS": ["arn:aws:iam::grantee-account-id:root"]}, "Resource": [ "arn:aws:glue:us-east-1:grantor-account-id:*" ] } ] }
nota

Si una tabla de la cuenta del concedente apunta a una ubicación de Amazon S3, es decir, también en la cuenta del concedente, el rol de IAM que se utiliza para ejecutar un trabajo de ETL en la cuenta del beneficiario debe tener permiso para enumerar y obtener los objetos de la cuenta del concedente.

Dado que el cliente de la cuenta A ya tiene permiso para crear y ejecutar trabajos de ETL, a continuación se muestran los pasos básicos para configurar un trabajo de ETL para el acceso entre cuentas:

  1. Permita el acceso a los datos entre cuentas (omitir este paso si el acceso entre cuentas de Amazon S3 ya está configurado).

    1. Actualice la política de bucket de Amazon S3 en la cuenta B para permitir el acceso entre cuentas desde la cuenta A.

    2. Actualizar la política de IAM de la cuenta A para permitir el acceso al bucket en la cuenta B.

  2. Permita acceso entre cuentas al Data Catalog.

    1. Cree o actualice la política de recursos asociada al Data Catalog en la cuenta B para permitir el acceso desde la cuenta A.

    2. Actualice la política de IAM de la cuenta A para permitir el acceso a Data Catalog en la cuenta B.

Registro multicuenta CloudTrail

Cuando un trabajo de AWS Glue extracción, transformación y carga (ETL) accede a los datos subyacentes de una tabla del catálogo de datos compartida mediante concesiones AWS Lake Formation entre cuentas, se produce un comportamiento de registro adicional AWS CloudTrail .

Para los fines de este análisis, la AWS cuenta que compartió la tabla es la cuenta del propietario y la cuenta con la que se compartió la tabla es la cuenta del destinatario. Cuando un trabajo de ETL de la cuenta del destinatario accede a los datos de la tabla de la cuenta del propietario, el CloudTrail evento de acceso a los datos que se añade a los registros de la cuenta del destinatario se copia en los registros de la cuenta del CloudTrail propietario. Esto es para que las cuentas del propietario puedan realizar un seguimiento de los accesos a datos de las distintas cuentas de destinatarios. De forma predeterminada, los CloudTrail eventos no incluyen un identificador principal legible por humanos (ARN principal). Un administrador en la cuenta del destinatario puede optar por incluir el ARN principal en los registros.

Para obtener más información, consulte el CloudTrailregistro entre cuentas en la AWS Lake Formation Guía para desarrolladores.

Propiedad de recursos entre cuentas y facturación

Cuando un usuario de una AWS cuenta (cuenta A) crea un recurso nuevo, como una base de datos, en una cuenta diferente (cuenta B), ese recurso pasa a ser propiedad de la cuenta B, la cuenta en la que se creó. Un administrador de la cuenta B obtiene automáticamente permisos completos para obtener acceso al nuevo recurso, como leer, escribir y conceder permisos de acceso a una tercera cuenta. El usuario de la cuenta A puede obtener acceso al recurso que acaba de crear solo si tienen los permisos adecuados concedidos por la cuenta B.

Los costos de almacenamiento y otros costos que guardan relación directa con el nuevo recurso se facturan a la cuenta B, el propietario de los recursos. El costo de las solicitudes de ese usuario que creó el recurso se factura a la cuenta del solicitante, la cuenta A.

Para obtener más información sobre la AWS Glue facturación y los precios, consulta Cómo funcionan AWS los precios.

Limitaciones de acceso entre cuentas

El acceso entre cuentas de AWS Glue tiene las siguientes limitaciones:

  • No se permite el acceso entre cuentas a AWS Glue si ha creado bases de datos y tablas con Amazon Athena o Amazon Redshift Spectrum antes de tener la compatibilidad de una región con AWS Glue y la cuenta del propietario de los recursos no ha migrado el catálogo de datos de Amazon Athena a AWS Glue. Puede encontrar el estado de migración actual utilizando GetCatalogImportStatus (get_catalog_import_status). Para obtener más información sobre cómo migrar un catálogo de Athena aAWS Glue, consulte Actualización al AWS Glue Data Catalog step-by-step en la Guía del usuario de Amazon Athena.

  • El acceso entre cuentas solo se soporta para los recursos de Data Catalog, como bases de datos, tablas, funciones definidas por el usuario y conexiones.

  • El acceso entre cuentas a Data Catalog de Athena exige que registre el catálogo como un recurso DataCatalog de Athena. Para obtener instrucciones, consulte Registro de un AWS Glue Data Catalog desde otra cuenta en la Guía del usuario de Amazon Athena.