Octroi d'un accès intercompte

L'octroi d'un accès intercompte aux ressources du catalogue de données permet à vos tâches Extract-transform-load (ETL) d'interroger et de joindre des données provenant de comptes différents.

Méthodes d'octroi d'un accès intercompte dans AWS Glue

Vous pouvez octroyer l'accès à vos données aux comptes AWS externes à l'aide des méthodes AWS Glue ou des octrois intercomptes AWS Lake Formation. Les méthodes AWS Glue utilisent des politiques AWS Identity and Access Management (IAM) pour obtenir un contrôle précis des accès. Lake Formation utilise un modèle d'autorisations GRANT/REVOKE plus simple similaire aux commandes GRANT/REVOKE dans un système de base de données relationnelle.

Cette section décrit l'utilisation des méthodes AWS Glue. Pour de plus amples informations sur l'utilisation des autorisations intercomptes Lake Formation, consultez Octroi des autorisations Lake Formation dans le Guide du développeur AWS Lake Formation.

Il existe deux méthodes AWS Glue pour accorder un accès intercompte à une ressource :

Octroi d'un accès intercompte à l'aide d'une politique de ressource

Voici les étapes générales d'octroi d'un accès intercompte à l'aide d'une politique de ressource de catalogue de données :

Octroi d'un accès intercompte avec un rôle IAM

Voici les étapes générales d'octroi d'un accès intercompte à l'aide d'un rôle IAM :

Pour plus d'informations sur l'utilisation d'IAM pour déléguer des autorisations, veuillez consulter la section Access management (français non garanti) dans le Guide de l'utilisateur IAM. Pour plus d’informations sur les utilisateurs, les groupes, les rôles et les autorisations, consultez Identités (utilisateurs, groupes et rôles) dans le Guide de l’utilisateur IAM.

Pour une comparaison entre ces deux approches, veuillez consulter la rubrique Différence entre les rôles IAM et les politiques basées sur les ressources dans le Guide de l'utilisateur IAM. AWS Glue prend en charge les deux options, avec la restriction qu'une politique de ressources peut uniquement accorder l'accès aux ressources du catalogue de données.

Par exemple, pour accorder au rôle Dev du compte B l'accès à la base de données db1 du compte A, attachez la politique de ressources suivante au catalogue du compte A.

JSON

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

En outre, le compte B devrait attacher la politique IAM suivante au rôle Dev avant d'obtenir l'accès à db1 sur le compte A.

JSON

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

Ajouter ou mettre à jour la politique de ressource du catalogue de données

Vous pouvez ajouter ou mettre à jour la politique de ressource du catalogue de données AWS Glue à l'aide de la console, de l'API ou de AWS Command Line Interface (AWS CLI).

Créer un appel d'API intercompte

Toutes les opérations AWS Glue Data Catalog ont un champ CatalogId. Si les autorisations requises ont été accordées pour activer l'accès intercompte, un utilisateur peut créer des appels d'API du catalogue de données intercompte. L'appelant effectue cette opération en transmettant l'ID de compte AWS cible dans CatalogId afin d'accéder à la ressource de ce compte de destination.

Si aucune valeur CatalogId n'est fournie, AWS Glue utilise l'ID de compte de l'appelant par défaut, et l'appel n'est pas intercompte.

Créez un appel ETL intercompte

Certaines API PySpark et Scala AWS Glue ont un champ ID de catalogue. Si toutes les autorisations requises ont été accordées pour activer l'accès intercompte, une tâche ETL peut effectuer des appels PySpark et Scala vers des opérations d'API intercomptes en transmettant l'ID de compte AWS cible dans le champ ID de catalogue afin d'accéder aux ressources du catalogue de données dans un compte cible.

Si aucun ID de catalogue n'est fourni, AWS Glue utilise l'ID de compte de l'appelant par défaut, et l'appel n'est pas intercompte.

Pour les API PySpark qui prennent en charge catalog_id, consultez Classe GlueContext. Pour les API Scala qui prennent en charge catalogId, consultez Liste des API GlueContext Scala AWS Glue.

L'exemple suivant montre les autorisations requises par le bénéficiaire pour exécuter une tâche ETL. Dans cet exemple, grantee-account-id est l'catalog-id du client qui exécute la tâche et grantor-account-id est le propriétaire de la ressource. Cet exemple accorde l'autorisation à toutes les ressources de catalogue dans le compte du concédant. Pour limiter la portée des ressources accordées, vous pouvez fournir des ARN spécifique pour le catalogue, la base de données, la table et la connexion.

JSON

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

Étant donné que le client du Compte A est déjà autorisé à créer et exécuter des tâches ETL, les étapes élémentaires de configuration d'une tâche ETL pour l'accès intercompte sont les suivantes :

Journalisation inter-compte CloudTrail

Si une tâche d'extraction, transformation et chargement (ETL) AWS Glue accède aux données sous-jacentes d'une table de catalogue de données partagée via des autorisations intercomptes AWS Lake Formation, il existe d'autres comportements de journalisation AWS CloudTrail.

Aux fins de la présente discussion, le compte AWS qui a partagé la table est le compte propriétaire et le compte avec lequel la table a été partagée est le compte de destinataire. Lorsqu'une tâche ETL dans le compte destinataire accède aux données de la table du compte propriétaire, l'événement CloudTrail d'accès aux données qui est ajouté aux journaux du compte destinataire est copié dans les journaux CloudTrail du compte propriétaire. Cela permet aux comptes propriétaires de suivre les accès aux données par les différents comptes destinataires. Par défaut, les événements CloudTrail n'incluent pas d'identificateur du principal lisible par l'homme (ARN principal). Un administrateur du compte destinataire peut choisir d'inclure l'ARN du principal dans les journaux.

Pour plus d'informations, veuillez consulter la rubrique Journalisation intercompte CloudTrail dans le Guide du développeur AWS Lake Formation.

Propriété et facturation des ressources intercomptes

Lorsqu'un utilisateur dans un compte AWS (compte A) crée une ressource comme une base de données dans un compte différent (compte B), cette ressource est ensuite détenue par le compte B, le compte dans lequel elle a été créée. L'administrateur du Compte B obtient automatiquement des autorisations complètes pour accéder à la nouvelle ressource, y compris la lecture, l'écriture et l'octroi d'autorisations d'accès à un compte tiers. L'utilisateur du Compte A peut accéder à la ressource qu'il vient de créer uniquement s'il dispose des autorisations appropriées accordées par le Compte B.

Les coûts de stockage et les autres coûts directement liés à la nouvelle ressource sont facturés au Compte B, le propriétaire de la ressource. Le coût des demandes de l'utilisateur qui a créé la ressource est facturé au compte du demandeur, le Compte A.

Pour en savoir plus sur la facturation et la tarification de AWS Glue, consultez Fonctionnement de la tarification AWS.

Limitations des accès inter-comptes

AWS GlueL'accès intercompte à a les limitations suivantes :