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 Glue AWS

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 effectuer de tâches à l'aide de l'API AWS Management Console, AWS Command Line Interface (AWS CLI) ou de AWS l'API. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut 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 IAM (console) 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 ARNs format de chaque type de ressource, voir Actions, ressources et clés de condition pour AWS Glue dans le Service Authorization Reference.

Bonnes pratiques en matière de politiques

Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer les ressources AWS Glue de 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 :

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 ne s'appliquent qu'à des AWS Glue objects

Vous ne pouvez définir un contrôle précis que pour des objets spécifiques dans AWS Glue. Vous devez donc écrire la politique IAM de votre client afin que les opérations d'API qui autorisent Amazon Resource Names (ARNs) pour l'Resourceinstruction ne soient pas mélangées avec les opérations d'API qui ne l'autorisent ARNs pas.

Par exemple, la politique IAM suivante autorise les opérations d'API pour GetClassifier et GetJobRun. Il définit le Resource comme étant le * fait que AWS Glue n'autorise pas ARNs les classificateurs et les exécutions de tâches. Parce que ARNs sont autorisées pour des opérations d'API spécifiques telles que GetDatabase etGetTable, ARNs peuvent être spécifiées dans la seconde 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 une liste des AWS Glue objets qui le permettent ARNs, voirSpécification AWS Glue Ressource ARNs.

Utilisation de la console AWS Glue

Pour accéder à la console AWS Glue, vous devez disposer d'un minimum d'autorisations. Ces autorisations doivent vous permettre de répertorier et de consulter les détails des ressources AWS Glue de votre Compte AWS. Si vous créez une politique 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 politique.

Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l' AWS API. Autorisez plutôt l’accès à uniquement aux actions qui correspondent à l’opération d’API qu’ils tentent d’effectuer.

Pour garantir que les utilisateurs et les rôles peuvent toujours utiliser la console AWS Glue, associez également la AWS Glue ConsoleAccess ou la politique ReadOnly AWS gérée aux entités. Pour plus d’informations, consultez Ajout d’autorisations à un utilisateur dans le Guide de l’utilisateur IAM.

Pour qu'un utilisateur puisse travailler avec AWS Glue console, cet utilisateur doit disposer d'un ensemble minimal d'autorisations lui permettant de travailler avec AWS Glue ressources pour leur AWS compte. En plus de ceux-ci AWS Glue autorisations, la console a besoin des autorisations des services suivants :

Pour plus d'informations sur les autorisations dont les utilisateurs ont besoin pour consulter et utiliser AWS Glue console, voirÉtape 3 : associer une politique aux utilisateurs ou aux groupes qui accèdent 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 s'assurer que ces utilisateurs peuvent toujours utiliser le AWS Glue console, attachez également la politique AWSGlueConsoleFullAccess gérée comme décrit dansAWS 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 permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or 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 plus d'informations sur la ressource Amazon Resource Names (ARNs), consultezCatalogue de données ARNs.

{
  "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 GetTables autorisation

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 de votre AWS Glue Data Catalog soient organisées à l'aide de préfixes de nom. 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 accorder aux développeurs un accès complet à toutes les bases de données UDFs, tables, etc., qui portent le dev- préfixe. 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 * * ? *)"
        }
    ]
}

Le AWS Glue l'administrateur a attaché une valeur de balise Tom (aws:ResourceTag/Name": "Tom") au déclencheurt2. Le AWS Glue L'administrateur a également donné à Tom une politique IAM avec une déclaration de condition basée sur le tag. Par conséquent, Tom ne peut utiliser qu'un AWS Glue opération qui agit sur les ressources avec la valeur du tagTom.

{
    "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 permettre à Tom d'accéder àGetTriggers, AWS Glue L'administrateur crée une politique qui divise 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.

Dans l'exemple de politique suivant, toutes AWS Glue les opérations de travail 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 :

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

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

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 en matière de ressources selon laquelle AWS Glue subventions d'administrateur à Tom. Dans la première section de la politique, AWS Glue Les opérations d'API sont refusées pourGetTriggers. 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:VpcIdsglue:SubnetIds, etglue: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 de configuration du VPC ne proviennent pas directement de la CreateJob demande, mais sont déduites du champ « connexions » du travail qui pointe vers un AWS Glue connexion.

Exemple d’utilisation

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

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'un AWS Glue tâche sans spécifier d'informations de connexion.

Restreindre les sessions sur VPCs

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é de contexte (glue:CredentialIssuingService= glue.amazonaws.com) à chaque session de rôle qui AWS Glue met à la disposition du poste de travail 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 AWS Glue scripts. AWS Glue fournit une autre clé de contexte (glue:RoleAssumedBy=glue.amazonaws.com) à chaque session de rôle où AWS Glue appelle un autre AWS service au nom du client (pas par un point de terminaison job/dev, mais directement par le AWS Glue service).

Exemple d’utilisation

Spécifiez l'autorisation conditionnelle dans une politique IAM et attachez-la au rôle à utiliser par un AWS Glue travail. Cela garantit que certaines actions sont autorisées/refusées selon que la session de rôle est utilisée ou non pour un AWS Glue environnement d'exécution des tâches.

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