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. 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.
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)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) 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](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html) dans le *Service Authorization Reference*.
**Note**
Les exemples fournis dans cette section utilisent tous la région `us-west-2`. Vous pouvez le remplacer par la AWS région que vous souhaitez utiliser.
**Topics**
+ [Bonnes pratiques en matière de politiques](#security_iam_service-with-iam-policy-best-practices)
+ [Les autorisations au niveau des ressources s'appliquent uniquement à des objets AWS Glue spécifiques](#glue-identity-based-policy-limitations)
+ [Utilisation de la console AWS Glue](#security_iam_id-based-policy-examples-console)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Octroyer une autorisation en lecture seule à une table](#security_iam_id-based-policy-examples-read-only-table-access)
+ [Filtrer les tables par GetTables autorisation](#security_iam_id-based-policy-examples-filter-tables)
+ [Octroyer un accès complet à une table et à toutes les partitions](#security_iam_id-based-policy-examples-full-access-tables-partitions)
+ [Contrôler l'accès par préfixe du nom et refus explicite](#security_iam_id-based-policy-examples-deny-by-name-prefix)
+ [Octoyer l'accès à l'aide de balises](#tags-control-access-example-triggers-allow)
+ [Refuser l'accès à l'aide de balises](#tags-control-access-example-triggers-deny)
+ [Utiliser des balises avec les opérations d'API de liste et de lot](#tags-control-access-example-triggers-list-batch)
+ [Contrôler les paramètres à l'aide de clés de condition ou de contexte](#glue-identity-based-policy-condition-keys)
+ [Refus de la possibilité de créer des sessions d’aperçu des données à une identité](#deny-data-preview-sessions-per-identity)
## 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 :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez 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 d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez 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 par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM 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 plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 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. 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'`Resource`instruction 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 le définit `Resource` comme `*` étant donné qu'il 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` et`GetTable`, ARNs peuvent être spécifiées dans la seconde moitié de la politique.
------
#### [ JSON ]
****
```
{
"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:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/default",
"arn:aws:glue:us-east-1:111122223333:table/default/e*1*",
"arn:aws:glue:us-east-1:111122223333:connection/connection2"
]
}
]
}
```
------
Pour obtenir la liste des AWS Glue objets autorisés ARNs, voir[Spécification de AWS Glue la ressource ARNs](glue-specifying-resource-arns.md).
## 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) dans le *Guide de l’utilisateur IAM*.
Pour qu'un utilisateur puisse utiliser la AWS Glue console, il doit disposer d'un ensemble minimal d'autorisations lui permettant d'utiliser les AWS Glue ressources de son AWS compte. Outre ces autorisations AWS Glue, la console nécessite les autorisations des services suivants :
+ Autorisations Amazon CloudWatch Logs pour afficher les journaux.
+ Gestion des identités et des accès AWS (IAM) autorisations permettant de répertorier et de transmettre des rôles.
+ AWS CloudFormation autorisations pour travailler avec des piles.
+ Autorisations Amazon Elastic Compute Cloud (Amazon EC2) permettant de VPCs répertorier des sous-réseaux, des groupes de sécurité, des instances et d'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](attach-policy-iam-user.md).
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](security-iam-awsmanpol.md#access-policy-examples-aws-managed).
## 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), consultez[Catalogue de données ARNs](glue-specifying-resource-arns.md#data-catalog-resource-arns).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesActionOnBooks",
"Effect": "Allow",
"Action": [
"glue:GetTables",
"glue:GetTable"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333: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` :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:CreateTable"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:table/db1/tbl1",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333: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).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesExample",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/store_sales",
"arn:aws:glue:us-east-1:111122223333: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`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesExample2",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333: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`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesReturnAll",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/*"
]
}
]
}
```
------
Si aucun ARN de table n'est fourni, un appel de `GetTables` réussit, mais renvoie une liste vide.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesEmptyResults",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1"
]
}
]
}
```
------
Si l'ARN de la base de données est manquant dans la politique, un appel à `GetTables` échoue avec une erreur`AccessDeniedException`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesAccessDeny",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333: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.
------
#### [ JSON ]
****
```
{
"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-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/books"
]
}
]
}
```
------
La politique précédente peut être simplifiée dans la pratique.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FullAccessOnTable",
"Effect": "Allow",
"Action": [
"glue:*Table*",
"glue:*Partition*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333: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-`.
------
#### [ JSON ]
****
```
{
"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-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/dev-*",
"arn:aws:glue:us-east-1:111122223333:database/prod-*",
"arn:aws:glue:us-east-1:111122223333:table/dev-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/dev-*",
"arn:aws:glue:us-east-1:111122223333:table/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/dev-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/dev-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:connection/dev-*",
"arn:aws:glue:us-east-1:111122223333:connection/prod-*"
]
},
{
"Sid": "ProdWriteDeny",
"Effect": "Deny",
"Action": [
"glue:*Create*",
"glue:*Update*",
"glue:*Delete*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:database/prod-*",
"arn:aws:glue:us-east-1:111122223333:table/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/prod-*",
"arn:aws:glue:us-east-1:111122223333: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`.
------
#### [ JSON ]
****
```
{
"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`.
------
#### [ JSON ]
****
```
{
"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`.
## 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.
1. Refuser l'accès utilisateur aux opérations d'API `Get` telles que `GetCrawlers`, `GetDevEndponts`, `GetJobs` et `GetTriggers`.
1. 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`.
1. Refusez l'accès des utilisateurs au AWS Glue balisage APIs, tel que `TagResource` et`UntagResource`.
1. 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`.
------
#### [ JSON ]
****
```
{
"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](#glue-identity-based-policy-condition-key-vpc)
+ [Contrôler des politiques qui contrôlent les paramètres à l'aide des clés de contexte](#glue-identity-based-policy-context-key-glue)
### 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 de type AWS Glue 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'une tâche AWS Glue 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 est mise à la AWS Glue 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 les AWS Glue scripts. AWS Gluefournit une autre clé de contexte (`glue:RoleAssumedBy=glue.amazonaws.com`) à chaque session de rôle AWS Glue qui appelle un autre AWS service au nom du client (pas par un job/dev point de terminaison, mais directement par le AWS Glue service).
**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 allowed/denied basées sur le fait que la session de rôle est utilisée ou non pour un environnement d'exécution de AWS Glue tâches.
```
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-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*"
]
}
```