As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Concessão de acesso entre contas

Conceder acesso aos recursos do Data Catalog entre contas permite que seus trabalhos de extração, transformação e carregamento (ETL) consultem e juntem dados de contas diferentes.

Métodos de concessão de acesso entre contas no AWS Glue

Você pode conceder acesso aos seus dados a contas externas da AWS usando métodos do AWS Glue ou concessões entre contas do AWS Lake Formation. Os métodos do AWS Glue usam políticas do AWS Identity and Access Management (IAM) para obter um controle de acesso minucioso. O Lake Formation usa um modelo de permissões GRANT/REVOKE mais simples semelhante aos comandos GRANT/REVOKE em um sistema de banco de dados relacional.

Esta seção descreve o uso de métodos do AWS Glue. Para mais informações sobre como usar concessões entre contas do Lake Formation, consulte Conceder permissões do Lake Formation no Guia do desenvolvedor do AWS Lake Formation.

Há dois métodos do AWS Glue para conceder acesso entre contas a um recurso:

Usar uma política de recursos para conceder acesso entre contas

A seguir estão as etapas gerais para conceder acesso entre contas usando uma política de recursos do Data Catalog:

Conceder acesso entre contas utilizando uma função do IAM

A seguir estão as etapas gerais para conceder acesso entre contas usando uma função do IAM:

Para obter mais informações sobre o uso do IAM para delegar permissões, consulte Gerenciamento de acesso no Manual do usuário do IAM. Para obter mais informações sobre usuários, grupos, funções e permissões, consulte Identities (users, groups, and roles) no Guia do usuário do IAM.

Para obter uma comparação entre essas duas abordagens, consulte Como as funções do IAM diferem de políticas baseadas em recurso no Guia do usuário do IAM. O AWS Glue é compatível com ambas as opções, com a restrição de que uma política de recurso só pode conceder acesso aos recursos do Data Catalog.

Por exemplo, para conceder ao perfil Dev na conta B acesso ao banco de dados db1 na conta A, anexe a política de recurso a seguir ao catálogo na conta 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"
      ]
    }
  ]
}

Além disso, a conta B deve anexar a seguinte política do IAM ao perfil Devpara poder realmente ter acesso ao db1 na conta 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"
      ]
    }
  ]
}

Adição ou atualização da política de recursos do catálogo de dados

Você pode adicionar ou atualizar a política de recursos do catálogo de dados do AWS Glue usando o console, a API ou a AWS Command Line Interface (AWS CLI).

Realização de uma chamada de API entre contas

Todas as operações do AWS Glue Data Catalog têm um campo CatalogId. Se as permissões necessárias foram concedidas para habilitar o acesso entre contas, um autor da chamada pode fazer chamadas de API do Data Catalog entre contas. O autor da chamada faz isso transmitindo o ID da conta da AWS de destino no CatalogId para acessar o recurso nessa conta de destino.

Se nenhum valor de CatalogId for fornecido, o AWS Glue usará o ID da conta do próprio chamador por padrão, e a chamada não será entre contas.

Realização de uma chamada de ETL entre contas

Algumas APIs de PySpark e Scala do AWS Glue têm um campo de ID do catálogo. Se todas as permissões necessárias forem concedidas para habilitar o acesso entre contas, um trabalho de ETL poderá fazer chamadas de PySpark e Scala às operações da API entre contas transmitindo o ID da conta da AWS de destino no campo de ID do catálogo para acessar os recursos do Data Catalog em uma conta de destino.

Se nenhum valor de ID de catálogo for fornecido, o AWS Glue usará o ID da conta do próprio chamador por padrão, e a chamada não será entre contas.

Para APIs do PySpark que oferecem suporte ao catalog_id, consulte Classe GlueContext. Para APIs do Scala que oferecem suporte ao catalogId, consulte APIs GlueContext em Scala do AWS Glue.

O exemplo a seguir mostra as permissões exigidas pelo usuário autorizado para executar um trabalho de ETL. Neste exemplo, grantee-account-id é o catalog-id do cliente que executa a tarefa e grantor-account-id é o proprietário do recurso. Este exemplo concede permissão a todos os recursos do catálogo na conta do concessor. Para limitar o escopo de recursos concedidos, você pode fornecer ARNs específicos para o catálogo, o banco de dados, a tabela e a conexão.

{
    "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:*"
            ]
        }
    ]
}

Uma vez que o cliente na Conta A já tem permissão para criar e executar tarefas de ETL, as etapas básicas para configurar uma tarefa de ETL para acesso entre contas são:

Registro em log no CloudTrail entre contas

Quando um trabalho de extração, transformação e carregamento (ETL) do AWS Glue acessa os dados subjacentes de uma tabela do catálogo de dados compartilhada por concessões entre contas do AWS Lake Formation, há um comportamento de registro em log adicional do AWS CloudTrail.

Para efeitos desta discussão, a conta da AWS que compartilha a tabela é a conta de proprietário, já a conta com a qual a tabela é compartilhada é a conta de destinatário. Quando um trabalho de ETL na conta de destinatário acessa dados da tabela na conta de proprietário, o evento de acesso a dados do CloudTrail que é adicionado aos logs da conta de destinatário é copiado para os logs do CloudTrail da conta de proprietário. Isso é para que as contas de proprietário possam rastrear acessos a dados pelas várias contas de destinatários. Por padrão, os eventos do CloudTrail não incluem um identificador de entidade principal legível (ARN da entidade principal). Um administrador na conta de destinatário pode optar por incluir o ARN da entidade principal nos logs.

Para obter mais informações, consulte Registro em log entre contas do CloudTrail no Guia do desenvolvedor do AWS Lake Formation.

Propriedade e faturamento de recursos entre contas

Quando um usuário em uma conta da AWS (conta A) cria um novo recurso, como um banco de dados em outra conta (conta B), esse recurso é propriedade da conta B, a conta em que ele foi criado. Um administrador na Conta B automaticamente recebe permissões completas para acessar o novo recurso, incluindo leitura, gravação e concessão de permissões de acesso a uma conta de terceiros. O usuário na Conta A pode acessar o recurso que acabou de criar somente se tiver as permissões apropriadas concedidas pela Conta B.

Os custos de armazenamento e outros custos que estão diretamente associados ao novo recurso são cobrados da Conta B, a proprietária do recurso. O custo das solicitações do usuário que criou o recurso é faturado na conta do solicitante, a Conta A.

Para obter mais informações sobre faturamento e preços do AWS Glue, consulte Como funciona a definição de preços da AWS.

Limitações de acesso entre contas

O acesso entre contas do AWS Glue tem as seguintes limitações: