Exemples de politiques basées sur l'identité pour AWS Glue - AWS Glue
Bonnes pratiques en matière de politiquesLimitations des autorisations au niveau des ressourcesUtilisation de la consoleAutorisation accordée aux utilisateurs pour afficher leurs propres autorisationsAccès en lecture seule à une tableFiltrer les tablesAccès complet à la tablePréfixe du nom avec refusExemple de contrôle d'accès à l'aide d'identificationsRefuser l'accès à l'aide de balisesUtiliser des balises avec les opérations d'API de liste et de lotCréer des politiques qui contrôlent les paramètres à l'aide des clés de conditionRefus de la possibilité de créer des sessions d’aperçu des données à une identité

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Exemples de politiques basées sur l'identité pour AWS Glue

Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou modifier les ressources AWS Glue. Ils ne peuvent pas non plus exécuter des tâches à l'aide de la AWS Management Console, de l'AWS Command Line Interface (AWS CLI) ou de l'API AWS. Pour octroyer aux utilisateurs des autorisations d'effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM doit créer des politiques IAM. L'administrateur peut ensuite ajouter les politiques IAM aux rôles et les utilisateurs peuvent assumer les rôles.

Pour apprendre à créer une politique basée sur l'identité IAM à l'aide de ces exemples de documents de politique JSON, consultez Création de politiques dans l'onglet JSON dans le Guide de l'utilisateur IAM.

Pour plus de détails sur les actions et les types de ressources définis par AWS Glue, y compris le format des ARN pour chacun des types de ressources, veuillez consulter la rubrique Actions, ressources et clés de condition pour AWS Glue dans la Référence de l'autorisation de service.

Note

Les exemples fournis dans cette section utilisent tous la région us-west-2. Vous pouvez remplacer ceci par la région AWS que vous souhaitez utiliser.

Bonnes pratiques en matière de politiques

Les politiques basées sur l'identité déterminent si une personne peut créer, consulter ou supprimer des ressources AWS Glue sur votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :

  • Démarrer avec AWS gérées et évoluez vers les autorisations de moindre privilège - Pour commencer à accorder des autorisations à vos utilisateurs et charges de travail, utilisez les politiques gérées AWS qui accordent des autorisations dans de nombreux cas d’utilisation courants. Elles sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire encore les autorisations en définissant des politiques AWS gérées par le client qui sont spécifiques à vos cas d’utilisation. Pour de plus amples informations, consultez politiques gérées par AWS ou politiques gérées par AWS pour les activités professionnelles dans le Guide de l’utilisateur IAM.

  • Accorder les autorisations de moindre privilège - Lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées autorisations de moindre privilège. Pour plus d’informations sur l’utilisation de IAM pour appliquer des autorisations, consultez politiques et autorisations dans IAM dans le Guide de l’utilisateur IAM.

  • Utiliser des conditions dans les politiques IAM pour restreindre davantage l’accès - Vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l’accès aux actions de service si elles sont utilisées via un Service AWS spécifique, comme AWS CloudFormation. Pour plus d’informations, consultez Conditions pour éléments de politique JSON IAM dans le Guide de l’utilisateur IAM.

  • Utilisez IAM Access Analyzer pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles - IAM Access Analyzer valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour de plus amples informations, consultez Validation de politique IAM Access Analyzer dans le Guide de l’utilisateur IAM.

  • Authentification multifactorielle (MFA) nécessaire : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root dans votre Compte AWS, activez l’authentification multifactorielle pour une sécurité renforcée. Pour exiger le MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour de plus amples informations, consultez Configuration de l’accès aux API protégé par MFA dans le Guide de l’utilisateur IAM.

Pour plus d’informations sur les bonnes pratiques dans IAM, consultez Bonnes pratiques de sécurité dans IAM dans le Guide de l’utilisateur IAM.

Les autorisations au niveau des ressources s'appliquent uniquement à des objets AWS Glue spécifiques

Vous pouvez uniquement définir un contrôle précis pour certains objets dans AWS Glue. Par conséquent, vous devez écrire la politique IAM de votre client afin que les opérations d'API qui autorisent les Amazon Resource Names (ARN) pour l'instruction Resource ne se retrouvent pas mélangées avec des opérations d'API qui n'autorisent pas les ARN.

Par exemple, la politique IAM suivante autorise les opérations d'API pour GetClassifier et GetJobRun. Elle définit Resource comme *, car AWS Glue n'autorise pas les ARN pour les classificateurs et les exécutions de tâche. Dans la mesure où les ARN sont autorisés pour des opérations d'API spécifiques telles que GetDatabase et GetTable, les ARN peuvent être spécifiés dans la deuxième moitié de la politique.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "glue:GetClassifier*",
                "glue:GetJobRun*"
            ],
            "Resource": "*"   
        },
        {
            "Effect": "Allow",
            "Action": [
                "glue:Get*"
            ],
            "Resource": [
                "arn:aws:glue:us-east-1:123456789012:catalog",
                "arn:aws:glue:us-east-1:123456789012:database/default",
                "arn:aws:glue:us-east-1:123456789012:table/default/e*1*",
                "arn:aws:glue:us-east-1:123456789012:connection/connection2"
            ]
        }
    ]
}

Pour obtenir la liste des objets AWS Glue qui autorisent les ARN, consultez ARN de la ressource.

Utilisation de la console AWS Glue

Pour accéder à la console AWS Glue, vous devez disposer d'un ensemble minimal d'autorisations. Ces autorisations doivent vous permettre de répertorier et de consulter les informations relatives aux ressources AWS Glue de votre Compte AWS. Si vous créez une stratégie basée sur l'identité qui est plus restrictive que l'ensemble minimum d'autorisations requis, la console ne fonctionnera pas comme prévu pour les entités (utilisateurs ou rôles) tributaires de cette stratégie.

Vous n'avez pas besoin d'accorder les autorisations minimales de console pour les utilisateurs qui effectuent des appels uniquement à AWS CLI ou à l'API AWS. Autorisez plutôt l'accès à uniquement aux actions qui correspondent à l'opération d'API qu'ils tentent d'effectuer.

Pour vous assurer que les utilisateurs et les rôles puissent continuer à utiliser la console AWS Glue, attachez également la politique AWS Glue ConsoleAccess ou ReadOnly gérée par AWS aux entités. Pour plus d'informations, consultez Ajout d'autorisations à un utilisateur dans le Guide de l'utilisateur IAM.

Dans le cas d'un utilisateur qui travaille avec la console AWS Glue, il doit disposer d'un ensemble minimal d'autorisations qui lui permet de travailler avec les ressources AWS Glue de son compte AWS. Outre ces autorisations AWS Glue, la console nécessite les autorisations des services suivants :

  • Autorisations Amazon CloudWatch Logs pour afficher les journaux.

  • Autorisations AWS Identity and Access Management (IAM) pour répertorier et transmettre les rôles.

  • Autorisations AWS CloudFormation pour utiliser les piles.

  • Autorisations Amazon Elastic Compute Cloud (Amazon EC2) pour répertorier les VPC, les sous-réseaux, les groupes de sécurité, les instances et autres objets.

  • Autorisations Amazon Simple Storage Service (Amazon S3) pour répertorier les compartiments et les objets, et pour récupérer et enregistrer les scripts.

  • Autorisations Amazon Redshift requises pour travailler avec des clusters.

  • Autorisations Amazon Relational Database Service (Amazon RDS) pour répertorier les instances.

Pour plus d'informations sur les autorisations dont vos utilisateurs ont besoin pour afficher la console AWS Glue et l'utiliser, consultez Étape 3 : attacher une politique aux utilisateurs ou aux groupes accédant à AWS Glue.

Si vous créez une politique IAM plus restrictive que les autorisations minimales requises, la console ne fonctionnera pas comme prévu pour les utilisateurs dotés de cette politique IAM. Pour garantir que ces utilisateurs pourront continuer à utiliser la console AWS Glue, attachez également la politique gérée par AWSGlueConsoleFullAccess, comme décrit dans AWS politiques gérées (prédéfinies) pour AWS Glue.

Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations

Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d'afficher les politiques en ligne et gérées attachées à leur identité d'utilisateur. Cette politique inclut les autorisations nécessaires pour réaliser cette action sur la console ou par programmation à l’aide de l’AWS CLI ou de l’API AWS.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}

Octroyer une autorisation en lecture seule à une table

La politique suivante accorde une autorisation en lecture seule à une table nommée books dans la base de données nommée db1. Pour de plus amples informations sur l'utilisation des Amazon Resource Names (ARN), veuillez consulter ARN du catalogue de données.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GetTablesActionOnBooks",
      "Effect": "Allow",
      "Action": [
        "glue:GetTables",
        "glue:GetTable"        
      ],
      "Resource": [
        "arn:aws:glue:us-west-2:123456789012:catalog",      
        "arn:aws:glue:us-west-2:123456789012:database/db1",
        "arn:aws:glue:us-west-2:123456789012:table/db1/books"
      ]
    }
  ]
}

Cette politique accorde l'autorisation en lecture seule à une table nommée books dans la base de données nommée db1. Pour accorder une autorisation Get à une table, cette autorisation est également requise pour le catalogue et les ressources de base de données.

La politique suivante accorde les autorisations nécessaires minimales pour créer la table tb1 dans la base de données db1 :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "glue:CreateTable"
      ],
      "Resource": [
        "arn:aws:glue:us-west-2:123456789012:table/db1/tbl1",
        "arn:aws:glue:us-west-2:123456789012:database/db1",
        "arn:aws:glue:us-west-2:123456789012:catalog"        
      ]
    }
  ]
}

Filtrer les tables par autorisation GetTables

Supposons qu'il y ait trois tables, customers, stores et store_sales dans la base de données db1. La politique suivante octroie l'autorisation GetTables à stores et store_sales, mais pas à customers. Lorsque vous appelez GetTables avec cette politique, le résultat contient uniquement les deux tables autorisées (la table customers n'est pas renvoyée).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetTablesExample",
            "Effect": "Allow",
            "Action": [
                "glue:GetTables"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:database/db1",
                "arn:aws:glue:us-west-2:123456789012:table/db1/store_sales",
                "arn:aws:glue:us-west-2:123456789012:table/db1/stores"
            ]
        }
    ]
}

Vous pouvez simplifier la politique précédente en utilisant store* pour correspondre à tous les noms de table qui commencent par store.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetTablesExample2",
            "Effect": "Allow",
            "Action": [
                "glue:GetTables"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:database/db1",
                "arn:aws:glue:us-west-2:123456789012:table/db1/store*"
            ]
        }
    ]
}

De même, si vous utilisez /db1/* pour une correspondance avec toutes les tables db1, la politique suivante accorde l'accès GetTables à toutes les tables de db1.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetTablesReturnAll",
            "Effect": "Allow",
            "Action": [
                "glue:GetTables"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:database/db1",
                "arn:aws:glue:us-west-2:123456789012:table/db1/*"
            ]
        }
    ]
}

Si aucun ARN de table n'est fourni, un appel de GetTables réussit, mais renvoie une liste vide.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetTablesEmptyResults",
            "Effect": "Allow",
            "Action": [
                "glue:GetTables"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:database/db1"
            ]
        }
    ]
}

Si l'ARN de la base de données est manquant dans la politique, un appel à GetTables échoue avec une erreurAccessDeniedException.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetTablesAccessDeny",
            "Effect": "Allow",
            "Action": [
                "glue:GetTables"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:table/db1/*"
            ]
        }
    ]
}

Octroyer un accès complet à une table et à toutes les partitions

La politique suivante accorde toutes les autorisations sur une table nommée books dans la base de données db1. Cela inclut les autorisations de lecture et d'écriture sur la table elle-même, sur les versions archivées et sur toutes ses partitions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessOnTable",
            "Effect": "Allow",
            "Action": [
                "glue:CreateTable",
                "glue:GetTable",
                "glue:GetTables",                
                "glue:UpdateTable",
                "glue:DeleteTable",
                "glue:BatchDeleteTable",
                "glue:GetTableVersion",
                "glue:GetTableVersions",
                "glue:DeleteTableVersion",
                "glue:BatchDeleteTableVersion",
                "glue:CreatePartition",
                "glue:BatchCreatePartition",
                "glue:GetPartition",
                "glue:GetPartitions",
                "glue:BatchGetPartition",
                "glue:UpdatePartition",
                "glue:DeletePartition",
                "glue:BatchDeletePartition"
            ],
            "Resource": [
                        "arn:aws:glue:us-west-2:123456789012:catalog",
                        "arn:aws:glue:us-west-2:123456789012:database/db1",
                        "arn:aws:glue:us-west-2:123456789012:table/db1/books" 
                        ]
        }
    ]
}

La politique précédente peut être simplifiée dans la pratique.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessOnTable",
            "Effect": "Allow",
            "Action": [
                "glue:*Table*",
                "glue:*Partition*"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:database/db1",
                "arn:aws:glue:us-west-2:123456789012:table/db1/books"
            ]
        }
    ]
}

Notez que la granularité minimum d'un contrôle d'accès précis se trouve au niveau de la table. Cela signifie que vous ne pouvez pas accorder à un utilisateur l'accès à certaines partitions dans une table, mais pas à d'autres, ou à certaines colonnes de la table, mais pas à d'autres. Un utilisateur a soit accès à toute la table, soit à aucune partie de la table.

Contrôler l'accès par préfixe du nom et refus explicite

Dans cet exemple, supposons que les bases de données et les tables dans votre catalogue de données AWS Glue soient organisées à l'aide de préfixes de noms. Les bases de données à l'étape de développement ont le préfixe de nom dev- et celles en production ont le préfixe de nom prod-. Vous pouvez utiliser la politique suivante pour octroyer aux développeurs l'accès total à toutes les bases de données, les tables, les fonctions définies par l'utilisateur, etc., qui ont le préfixe dev-. Mais vous accordez un accès en lecture seule à tout avec le préfixe prod-.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DevAndProdFullAccess",
            "Effect": "Allow",
            "Action": [
                "glue:*Database*",
                "glue:*Table*",
                "glue:*Partition*",
                "glue:*UserDefinedFunction*",
                "glue:*Connection*"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",
                "arn:aws:glue:us-west-2:123456789012:database/dev-*",
                "arn:aws:glue:us-west-2:123456789012:database/prod-*",
                "arn:aws:glue:us-west-2:123456789012:table/dev-*/*",
                "arn:aws:glue:us-west-2:123456789012:table/*/dev-*",
                "arn:aws:glue:us-west-2:123456789012:table/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:table/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/dev-*/*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/dev-*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:connection/dev-*",
                "arn:aws:glue:us-west-2:123456789012:connection/prod-*"
            ]
        },
        {
            "Sid": "ProdWriteDeny",
            "Effect": "Deny",
            "Action": [
                "glue:*Create*",
                "glue:*Update*",
                "glue:*Delete*"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:database/prod-*",
                "arn:aws:glue:us-west-2:123456789012:table/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:table/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:connection/prod-*"
            ]
        }
    ]
}

La deuxième instruction de la politique précédente utilise le explicite deny. Vous pouvez utiliser le deny explicite pour remplacer toutes les autorisations allow qui sont accordées au principal. Cela vous permet de verrouiller l'accès aux ressources critiques et d'éviter qu'une autre politique accorde un accès à celles-ci par accident.

Dans l'exemple précédent, même si la première instruction accorde un accès complet aux ressources prod-, la deuxième instruction révoque explicitement l'accès en écriture à celles-ci, laissant uniquement l'accès en lecture aux ressources prod-.

Octoyer l'accès à l'aide de balises

Par exemple, supposons que vous souhaitiez limiter l'accès à un déclencheur t2 à un utilisateur spécifique nommé Tom dans votre compte. Tous les autres utilisateurs, y compris Sam, ont accès au déclencheur t1. Les déclencheurs t1 et t2 ont les propriétés suivantes. 

aws glue get-triggers
{
    "Triggers": [
        {
            "State": "CREATED",
            "Type": "SCHEDULED",
            "Name": "t1",
            "Actions": [
                {
                    "JobName": "j1"
                }
            ],
            "Schedule": "cron(0 0/1 * * ? *)"
        },
        {
            "State": "CREATED",
            "Type": "SCHEDULED",
            "Name": "t2",
            "Actions": [
                {
                    "JobName": "j1"
                }
            ],
            "Schedule": "cron(0 0/1 * * ? *)"
        }
    ]
}

L'administrateur AWS Glue a attaché une valeur de balise Tom (aws:ResourceTag/Name": "Tom") au déclencheur t2. L'administrateur AWS Glue a également donné à Tom une politique IAM avec une instruction de condition basée sur la balise. Par conséquent, Tom peut uniquement utiliser une opération AWS Glue qui agit sur les ressources avec la valeur de balise Tom. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
         "Effect": "Allow",
         "Action": "glue:*",
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                "aws:ResourceTag/Name": "Tom"
              }
          }
         }
    ]
}

Lorsque Tom essaie d'accéder au déclencheur t1, il reçoit un message d'accès refusé. Dans le même temps, il parvient à récupérer le déclencheur t2. 

aws glue get-trigger --name t1

An error occurred (AccessDeniedException) when calling the GetTrigger operation: User: Tom is not authorized to perform: glue:GetTrigger on resource: arn:aws:glue:us-east-1:123456789012:trigger/t1

aws glue get-trigger --name t2
{
    "Trigger": {
        "State": "CREATED",
        "Type": "SCHEDULED",
        "Name": "t2",
        "Actions": [
            {
                "JobName": "j1"
            }
        ],
        "Schedule": "cron(0 0/1 * * ? *)"
    }
}

Tom ne peut pas utiliser l'opération d'API plurielle GetTriggers pour répertorier les déclencheurs, car celle-ci ne prend pas en charge le filtrage des balises.

Pour accorder à Tom l'accès à GetTriggers, l'administrateur AWS Glue crée une politique qui fractionne les autorisations en deux sections. Une section autorise Tom à accéder à tous les déclencheurs avec l'opération d'API GetTriggers. La deuxième section autorise Tom à accéder aux opérations d'API qui sont balisées avec la valeur Tom. Avec cette politique, Tom est autorisé à accéder à la fois à GetTriggers et à GetTrigger pour déclencher t2. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "glue:GetTriggers",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "glue:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Name": "Tom"
                }
            }
        }
    ]
}

Refuser l'accès à l'aide de balises

Une autre approche de politique de ressource consiste à refuser explicitement l'accès aux ressources.

Important

Une politique de refus explicite ne fonctionne pas pour les opérations d'API plurielles telles que GetTriggers.

Dans l'exemple de politique suivant, toutes les opérations de tâche AWS Glue sont autorisées. Cependant, la deuxième instruction Effect refuse explicitement l'accès aux tâches balisées avec la clé Team et la valeur Special.

Lorsqu'un administrateur attache la politique suivante à une identité, cette dernière peut accéder à toutes les tâches, sauf celles balisées avec la clé Team et la valeur Special. 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "glue:*",
      "Resource": "arn:aws:glue:us-east-1:123456789012:job/*"
    },
    {
      "Effect": "Deny",
      "Action": "glue:*",
      "Resource": "arn:aws:glue:us-east-1:123456789012:job/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Team": "Special"
        }
      }
    }
  ]
}

Utiliser des balises avec les opérations d'API de liste et de lot

Une troisième approche possible pour écrire une politique de ressource consiste à autoriser l'accès aux ressources à l'aide d'une opération d'API List pour répertorier les ressources pour une valeur de balise. Ensuite, utilisez l'opération d'API Batch correspondante pour autoriser l'accès aux détails des ressources spécifiques. Avec cette approche, l'administrateur n'a pas besoin d'autoriser l'accès aux opérations d'API GetCrawlers, GetDevEndpoints, GetJobs ou GetTriggers plurielles. Au lieu de cela, vous pouvez permettre de répertorier les ressources avec les opérations d'API suivantes :

  • ListCrawlers

  • ListDevEndpoints

  • ListJobs

  • ListTriggers

De plus, vous pouvez permettre d'obtenir des détails sur les ressources individuelles avec les opérations d'API suivantes :

  • BatchGetCrawlers

  • BatchGetDevEndpoints

  • BatchGetJobs

  • BatchGetTriggers

En tant qu'administrateur, pour utiliser cette approche, vous pouvez effectuer les opérations suivantes :

  1. Ajouter des balises à vos crawlers, points de terminaison de développement, tâches et déclencheurs.

  2. Refuser l'accès utilisateur aux opérations d'API Get telles que GetCrawlers, GetDevEndponts, GetJobs et GetTriggers.

  3. Pour permettre aux utilisateurs de déterminer à quelles ressources balisées ils ont accès, autorisez l'accès utilisateur aux opérations d'API List telles que ListCrawlers, ListDevEndponts, ListJobs et ListTriggers.

  4. Refusez à l'utilisateur l'accès aux API de balisage AWS Glue, telles que TagResource et UntagResource.

  5. Autorisez l'utilisateur à accéder aux détails de ressources à l'aide des opérations d'API BatchGet telles que BatchGetCrawlers, BatchGetDevEndponts, BatchGetJobs et BatchGetTriggers.

Par exemple, lorsque vous appelez l'opération ListCrawlers, fournissez une valeur de balise pour correspondre au nom d'utilisateur. Ensuite, le résultat est une liste d'crawlers qui correspondent aux valeurs de balise fournies. Fournissez la liste de noms à BatchGetCrawlers pour obtenir des détails sur chaque crawler avec la balise donnée.

Par exemple, si Tom ne doit être en mesure de récupérer que les détails des déclencheurs balisés avec Tom, l'administrateur peut ajouter des balises aux déclencheurs pour Tom, refuser à tous les utilisateurs l'accès à l'opération d'API GetTriggers et autoriser tous les utilisateurs à accéder à ListTriggers et à BatchGetTriggers.

Voici la politique de ressources que l'administrateur AWS Glue accorde à Tom. Dans la première section de la politique, les opérations d'API AWS Glue sont refusées pour GetTriggers. Dans la deuxième section de la politique, les opérations ListTriggers sont autorisées pour toutes les ressources. Toutefois, dans la troisième section, les ressources balisées avec Tom sont autorisées à accéder avec l'accès BatchGetTriggers. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "glue:GetTriggers",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "glue:ListTriggers"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "glue:BatchGetTriggers"
            ],
            "Resource": [
                "*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Name": "Tom"
                }
            }
        }
    ]
}

En utilisant les mêmes déclencheurs que dans l'exemple précédent, Tom peut accéder au déclencheur t2, mais pas au déclencheur t1. L'exemple suivant montre les résultats lorsque Tom essaie d'accéder à t1 et t2 avec BatchGetTriggers. 

aws glue batch-get-triggers --trigger-names t2
{
    "Triggers": {
        "State": "CREATED",
        "Type": "SCHEDULED",
        "Name": "t2",
        "Actions": [
            {
                "JobName": "j2"
            }
        ],
        "Schedule": "cron(0 0/1 * * ? *)"
    }
}

aws glue batch-get-triggers  --trigger-names t1

An error occurred (AccessDeniedException) when calling the BatchGetTriggers operation: No access to any requested resource.

L'exemple suivant montre les résultats lorsque Tom essaie d'accéder au déclencheur t2 et au déclencheur t3 (qui n'existe pas) dans le même appel BatchGetTriggers. Notez que, comme Tom a accès au déclencheur t2 et qu'il existe, seul t2 est renvoyé. Tom est autorisé à accéder au déclencheur t3, mais le déclencheur t3 n'existe pas, si bien que t3 est renvoyé comme réponse dans une liste de "TriggersNotFound": []. 

aws glue batch-get-triggers --trigger-names t2 t3
{
    "Triggers": {
        "State": "CREATED",
        "Type": "SCHEDULED",
        "Name": "t2",
        "Actions": [
            {
                "JobName": "j2"
            }
        ],
        "TriggersNotFound": ["t3"],
        "Schedule": "cron(0 0/1 * * ? *)"
    }
}

Contrôler les paramètres à l'aide de clés de condition ou de contexte

Vous pouvez utiliser des clés de condition ou des clés contextuelles lorsque vous accordez des autorisations de création et de mise à jour de tâches. Ces sections traitent des clés :

Contrôler des politiques qui contrôlent les paramètres à l'aide des clés de condition

AWS Glue fournit trois clés de condition IAM glue:VpcIds, glue:SubnetIds et glue:SecurityGroupIds. Vous pouvez utiliser les clés de condition dans les politiques IAM lorsque vous accordez des autorisations de création et de mise à jour de tâches. Vous pouvez utiliser ce paramètre pour vous assurer que les tâches ou les sessions ne sont pas créées (ou mises à jour vers) pour s'exécuter en dehors de l'environnement VPC souhaité. Les informations sur les paramètres du VPC ne sont pas une entrée directe provenant de la demande CreateJob, mais déduites du champ « connexions » de la tâche qui pointe vers une connexion AWS Glue.

Exemple d’utilisation

Créez une connexion AWS Glue de type réseau nommée « traffic-monitored-connection » avec le VpcId « vpc-id1234 », les SubnetIds et les SecurityGroupIds souhaités.

Spécifiez la condition des clés de condition pour le CreateJob et UpdateJob dans la politique IAM.

{
  "Effect": "Allow",
  "Action": [
    "glue:CreateJob",
    "glue:UpdateJob"
  ],
  "Resource": [
    "*"
  ],
  "Condition": {
    "ForAnyValue:StringLike": {
      "glue:VpcIds": [
        "vpc-id1234"
      ]
    }
  }
}

Vous pouvez créer une politique IAM similaire pour interdire la création d'une tâche AWS Glue sans spécifier d'informations de connexion.

Restreindre les sessions sur les VPC

Pour obliger les sessions créées à s'exécuter au sein d'un VPC spécifique, vous limitez l'autorisation des rôles en ajoutant un effet Deny sur l'action glue:CreateSession à la condition que le glue:vpc-id ne soit pas égal à vpc-<123>. Par exemple : 

"Effect": "Deny",
"Action": [
    "glue:CreateSession"
 ],
"Condition": {
    "StringNotEquals" : {"glue:VpcIds" : ["vpc-123"]} 
}

Vous pouvez également obliger les sessions créées à s'exécuter au sein d'un VPC en ajoutant un effet Deny sur l'action glue:CreateSession à la condition que le glue:vpc-id soit nul. Par exemple : 

{
    "Effect": "Deny",
    "Action": [
        "glue:CreateSession"
    ],
      "Condition": {
        "Null": {"glue:VpcIds": true}
    }
}, 
{
    "Effect": "Allow",
    "Action": [
        "glue:CreateSession"
    ],
    "Resource": ["*"]
}

Contrôler des politiques qui contrôlent les paramètres à l'aide des clés de contexte

AWS Glue fournit une clé contextuelle (glue:CredentialIssuingService= glue.amazonaws.com) à chaque session de rôle qui AWS Glue met à la disposition du poste et du point de terminaison du développeur. Cela vous permet de mettre en œuvre des contrôles de sécurité pour les actions entreprises par des scripts AWS Glue. AWS Glue fournit une autre clé de contexte (glue:RoleAssumedBy=glue.amazonaws.com) à chaque séance de rôle où AWS Glue appelle un autre service AWS au nom du client (non pas par un point de terminaison de tâche ou de développement, mais directement par le service AWS Glue).

Exemple d’utilisation

Indiquez l'autorisation conditionnelle dans la politique IAM et attachez-la au rôle à utiliser par une tâche AWS Glue. Cela garantit que certaines actions sont autorisées/refusées selon que la séance de rôle est utilisée pour un environnement d'exécution de tâche AWS Glue.

{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::confidential-bucket/*",
    "Condition": {
        "StringEquals": {
            "glue:CredentialIssuingService": "glue.amazonaws.com"
        }
    }
}

Refus de la possibilité de créer des sessions d’aperçu des données à une identité

Cette section contient un exemple de politique IAM utilisé pour refuser à une identité la possibilité de créer des sessions d’aperçu des données. Associez cette politique à l’identité, qui est distincte du rôle utilisé par la session d’aperçu des données lors de son exécution.

{
    "Sid": "DatapreviewDeny",
    "Effect": "Deny",
     "Action": [
           "glue:CreateSession"
     ],
     "Resource": [
          "arn:aws:glue:*:*:session/glue-studio-datapreview*"
      ]
 }