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 des ressources AWS Glue. Ils ne peuvent pas non plus effectuer de tâches en utilisant le AWS Management Console, AWS Command Line Interface (AWS CLI) ou AWS API. Pour autoriser les utilisateurs à effectuer des actions sur les ressources dont ils ont besoin, un IAM administrateur peut créer des IAM politiques. L'administrateur peut ensuite ajouter les IAM politiques aux rôles, et les utilisateurs peuvent assumer les rôles.

Pour savoir comment créer une politique IAM basée sur l'identité à l'aide de ces exemples de documents de JSON stratégie, voir Créer des IAM politiques (console) dans le guide de l'IAMutilisateur.

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 meilleures pratiques en matière de sécuritéIAM, consultez la section Bonnes pratiques en matière de sécurité IAM dans le Guide de IAM l'utilisateur.

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 rédiger la IAM politique de votre client afin que les API opérations qui autorisent Amazon Resource Names (ARNs) pour l'Resourceinstruction ne soient pas mélangées à API des opérations non autoriséesARNs.

Par exemple, la IAM politique suivante autorise API les opérations pour GetClassifier etGetJobRun. 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 API opérations 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 permettentARNs, voirSpécification de AWS Glue la 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 le AWS CLI ou le AWS API. Au lieu de cela, autorisez uniquement l'accès aux actions correspondant à l'APIopération 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 la section Ajouter des autorisations à un utilisateur dans le Guide de IAM l'utilisateur.

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 IAM politique plus restrictive que les autorisations minimales requises, la console ne fonctionnera pas comme prévu pour les utilisateurs dotés de cette IAM politique. 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 IAM utilisateurs de consulter les politiques intégrées et gérées associées à leur identité d'utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide du AWS CLI ou. AWS API

{
    "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 aucune table n'ARNest fournie, un appel à GetTables aboutit, mais il 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 la base de données ARN est absente de la politique, un appel à GetTables échoue avec unAccessDeniedException.

{
    "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éesUDFs, 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 IAM politique 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'GetTriggersAPIopération pluriel pour répertorier les déclencheurs car cette opération ne prend pas en charge le filtrage sur les 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 permet à Tom d'accéder à tous les déclencheurs lors de l'GetTriggersAPIopération. La deuxième section permet à Tom d'accéder aux API opérations étiquetées avec la valeurTom. 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 pour les API opérations de liste et de traitement par lots

Une troisième approche pour écrire une politique de ressources consiste à autoriser l'accès aux ressources à l'aide d'une List API opération visant à répertorier les ressources pour une valeur de balise. Utilisez ensuite l'BatchAPIopération correspondante pour autoriser l'accès aux détails de ressources spécifiques. Avec cette approche, l'administrateur n'a pas besoin d'autoriser l'accès au plurielGetCrawlers, GetDevEndpointsGetJobs, ou aux GetTriggers API opérations. Au lieu de cela, vous pouvez autoriser la possibilité de répertorier les ressources à l'aide API des opérations suivantes :

De plus, vous pouvez autoriser l'obtention de détails sur des ressources individuelles en effectuant les API opérations 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 peut récupérer que les détails des déclencheurs marqués avecTom, l'administrateur peut ajouter des balises aux déclencheurs pourTom, refuser l'accès à l'GetTriggersAPIopération à tous les utilisateurs et autoriser l'accès à tous les utilisateurs à ListTriggers etBatchGetTriggers.

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 APIles opérations 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 IAM condition glue:VpcIdsglue:SubnetIds, etglue:SecurityGroupIds. Vous pouvez utiliser les clés de condition dans les IAM politiques lorsque vous accordez des autorisations pour créer et mettre à jour des 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) pour s'exécuter en dehors de VPC l'environnement souhaité. Les informations de VPC réglage 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 l'UpdateJobaction CreateJob et dans la IAM politique.

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

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

Restreindre les sessions sur VPCs

<123>Pour obliger les sessions créées à s'exécuter dans une zone spécifiéeVPC, vous limitez l'autorisation du rôle en ajoutant un Deny effet sur l'glue:CreateSessionaction à la condition que le glue:vpc-id ne soit pas égal à vpc-. Par exemple :

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

Vous pouvez également obliger les sessions créées à s'exécuter dans un en VPC ajoutant un Deny effet sur l'glue:CreateSessionaction à 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 (non pas par un point de terminaison job/dev, mais directement par AWS Glue service).

Exemple d’utilisation

Spécifiez l'autorisation conditionnelle dans une IAM politique et associez-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 IAM de politique utilisé pour refuser à une identité la possibilité de créer des sessions de prévisualisation 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*"
      ]
 }