# Ejemplos de políticas basadas en identidades para AWS Glue
De forma predeterminada, los usuarios y los roles no tienen permiso para crear ni para modificar recursos de AWS Glue. Un administrador de IAM puede crear políticas de IAM para conceder permisos a los usuarios para realizar acciones en los recursos que necesitan.
Para obtener información acerca de cómo crear una política basada en identidades de IAM mediante el uso de estos documentos de políticas JSON de ejemplo, consulte [Creación de políticas de IAM (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) en la *Guía del usuario de IAM*.
Para obtener más información sobre las acciones y los tipos de recursos definidos por AWS Glue, incluido el formato de los ARN para cada tipo de recurso, consulte [Acciones, recursos y claves de condición para AWS Glue](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html) en la *Referencia de autorizaciones de servicio*.
**nota**
Todos los ejemplos que se proporcionan en esta sección utilizan la región `us-west-2`. Puede reemplazarla por la región de AWS que desee usar.
**Topics**
+ [Prácticas recomendadas sobre las políticas](#security_iam_service-with-iam-policy-best-practices)
+ [Los permisos de nivel de recursos solo se aplican a objetos específicos de AWS Glue.](#glue-identity-based-policy-limitations)
+ [Uso de la consola de AWS Glue](#security_iam_id-based-policy-examples-console)
+ [Cómo permitir a los usuarios consultar sus propios permisos](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Conceder permiso de solo lectura a una tabla](#security_iam_id-based-policy-examples-read-only-table-access)
+ [Filtrar tablas por permiso GetTables](#security_iam_id-based-policy-examples-filter-tables)
+ [Conceder acceso completo a una tabla y todas las particiones](#security_iam_id-based-policy-examples-full-access-tables-partitions)
+ [Controlar el acceso mediante prefijo de nombre y denegación explícita](#security_iam_id-based-policy-examples-deny-by-name-prefix)
+ [Conceder acceso mediante etiquetas](#tags-control-access-example-triggers-allow)
+ [Denegar acceso mediante etiquetas](#tags-control-access-example-triggers-deny)
+ [Usar etiquetas con las operaciones de API List y Batch](#tags-control-access-example-triggers-list-batch)
+ [Controlar la configuración mediante claves de condición o claves de contexto](#glue-identity-based-policy-condition-keys)
+ [Cómo denegar a una identidad la capacidad de crear sesiones de vista previa de datos](#deny-data-preview-sessions-per-identity)
## Prácticas recomendadas sobre las políticas
Las políticas basadas en identidades determinan si alguien puede crear o eliminar los recursos de AWS Glue en la cuenta y también si pueden acceder a ellos. Estas acciones pueden generar costos adicionales para su Cuenta de AWS. Siga estas directrices y recomendaciones al crear o editar políticas basadas en identidades:
+ **Comience a utilizar las políticas administradas de AWS y avance hacia permisos de privilegios mínimos**. Para empezar a conceder permisos a los usuarios y cargas de trabajo, utilice las *políticas administradas de AWS* que otorgan permisos para muchos casos de uso comunes. Están disponibles en su Cuenta de AWS. Se recomienda definir políticas administradas por el cliente de AWS específicas para sus casos de uso a fin de reducir aún más los permisos. Con el fin de obtener más información, consulte las [políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o las [políticas administradas por AWS para funciones de tarea](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) en la *Guía de usuario de IAM*.
+ **Aplique permisos de privilegio mínimo**: cuando establezca permisos con políticas de IAM, conceda solo los permisos necesarios para realizar una tarea. Para ello, debe definir las acciones que se pueden llevar a cabo en determinados recursos en condiciones específicas, también conocidos como *permisos de privilegios mínimos*. Con el fin de obtener más información sobre el uso de IAM para aplicar permisos, consulte [Políticas y permisos en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) en la *Guía del usuario de IAM*.
+ **Utilice condiciones en las políticas de IAM para restringir aún más el acceso**: puede agregar una condición a sus políticas para limitar el acceso a las acciones y los recursos. Por ejemplo, puede escribir una condición de políticas para especificar que todas las solicitudes deben enviarse utilizando SSL. También puede usar condiciones para conceder acceso a acciones de servicios si se emplean a través de un Servicio de AWS determinado como, por ejemplo, CloudFormation. Para obtener más información, consulte [Elementos de la política de JSON de IAM: Condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) en la *Guía del usuario de IAM*.
+ **Utiliza el analizador de acceso de IAM para validar las políticas de IAM con el fin de garantizar la seguridad y funcionalidad de los permisos**: el analizador de acceso de IAM valida políticas nuevas y existentes para que respeten el lenguaje (JSON) de las políticas de IAM y las prácticas recomendadas de IAM. El analizador de acceso de IAM proporciona más de 100 verificaciones de políticas y recomendaciones procesables para ayudar a crear políticas seguras y funcionales. Para más información, consulte [Validación de políticas con el Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) en la *Guía del usuario de IAM*.
+ **Solicite la autenticación multifactor (MFA)**: si se encuentra en una situación en la que necesite usuarios raíz o de IAM en su Cuenta de AWS, active la MFA para obtener una mayor seguridad. Para exigir la MFA cuando se invoquen las operaciones de la API, añada condiciones de MFA a sus políticas. Para más información, consulte [Acceso seguro a la API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) en la *Guía del usuario de IAM*.
Para obtener más información sobre las prácticas recomendadas de IAM, consulte [Prácticas recomendadas de seguridad en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) en la *Guía del usuario de IAM*.
## Los permisos de nivel de recursos solo se aplican a objetos específicos de AWS Glue.
Solo puede definir un control detallado para los objetos específicos de AWS Glue. Por lo tanto, debe escribir la política de IAM de sus clientes de modo que las operaciones API que permiten utilizar nombres de recursos de Amazon (Amazon Resource Names, ARN) con la instrucción `Resource` no se mezclen con las operaciones API que no permiten el uso de ARN.
Por ejemplo, la siguiente política de IAM permite operaciones de la API para `GetClassifier` y `GetJobRun`. Define el `Resource` como `*` porque AWS Glue no permite ARN para clasificadores y ejecuciones de trabajo. Dado que se permite utilizar ARN con determinadas operaciones API, como `GetDatabase` y `GetTable`, se pueden especificar ARN en la segunda mitad de la política.
------
#### [ 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"
]
}
]
}
```
------
Para ver una lista de objetos de AWS Glue que permiten el uso de ARN, consulte [Especificación de ARN del recurso de AWS Glue](glue-specifying-resource-arns.md).
## Uso de la consola de AWS Glue
Para acceder a la consola de AWS Glue, debe tener un conjunto mínimo de permisos. Estos permisos deben permitirle enumerar y consultar detalles sobre los recursos de AWS Glue en su Cuenta de AWS. Si crea una política basada en identidades que sea más restrictiva que el mínimo de permisos necesarios, la consola no funcionará del modo esperado para las entidades (usuarios o roles) que tengan esa política.
No es necesario conceder permisos mínimos para la consola a los usuarios que solo realizan llamadas a la AWS CLI o a la API de AWS. En su lugar, permita el acceso únicamente a las acciones que coincidan con la operación de API que intentan realizar.
Para asegurarse de que los usuarios y los roles puedan seguir utilizando la consola de AWS Glue, también asocie a las entidades la política administrada por AWS `ConsoleAccess` o `ReadOnly` de AWS Glue. Para obtener más información, consulte [Adición de permisos a un usuario](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) en la *Guía del usuario de IAM*:
Para que un usuario pueda trabajar con la consola de AWS Glue, debe tener un conjunto mínimo de permisos que le permitan trabajar con los recursos de AWS Glue en su cuenta de AWS. Además de estos permisos de AWS Glue, la consola requiere permisos de los servicios a continuación:
+ Permisos de Amazon CloudWatch Logs para mostrar registros.
+ AWS Identity and Access ManagementPermisos de (IAM) para enumerar y transferir roles.
+ AWS CloudFormationPermisos para trabajar con pilas.
+ Permisos de Amazon Elastic Compute Cloud (Amazon EC2) para enumerar VPC, subredes, grupos de seguridad, instancias y otros objetos.
+ Permisos de Amazon Simple Storage Service (Amazon S3) para enumerar buckets y objetos, y recuperar y guardar scripts.
+ Permisos necesarios de Amazon Redshift para trabajar con clústeres.
+ Permisos de Amazon Relational Database Service (Amazon RDS) para enumerar instancias.
Para obtener más información sobre los permisos que necesitan los usuarios para ver y trabajar con la consola de AWS Glue, consulte [Paso 3: Adjuntar una política a los usuarios o los grupos que accedan a AWS Glue](attach-policy-iam-user.md).
Si crea una política de IAM que sea más restrictiva que el mínimo de permisos necesarios, la consola no funcionará del modo esperado para los usuarios con esa política de IAM. Para asegurarse de que esos usuarios puedan seguir usando la consola de AWS Glue, asocie también la política administrada `AWSGlueConsoleFullAccess`, según se explica en [AWS Políticas administradas (predefinidas) por para AWS Glue](security-iam-awsmanpol.md#access-policy-examples-aws-managed).
## Cómo permitir a los usuarios consultar sus propios permisos
En este ejemplo, se muestra cómo podría crear una política que permita a los usuarios de IAM ver las políticas administradas e insertadas que se asocian a la identidad de sus usuarios. Esta política incluye permisos para llevar a cabo esta acción en la consola o mediante programación con la AWS CLI o la API de 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": "*"
}
]
}
```
## Conceder permiso de solo lectura a una tabla
La siguiente política concede permiso de solo lectura a una tabla `books` en la base de datos `db1`. Para obtener más información sobre nombres de recursos de Amazon (Amazon Resource Names, ARN), consulte [ARN de Data Catalog](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"
]
}
]
}
```
------
Esta política concede permisos de solo lectura a una tabla denominada `books` en la base de datos denominada `db1`. Para conceder un permiso `Get` a una tabla, también se requiere permiso para el catálogo y los recursos de la base de datos.
La siguiente política concede los permisos mínimos necesarios crear una tabla `tb1` en la base de datos `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"
]
}
]
}
```
------
## Filtrar tablas por permiso GetTables
Supongamos que hay tres tablas: `customers`, `stores` y `store_sales` en base de datos `db1`. La siguiente política concede permiso `GetTables` a `stores` y `store_sales`, pero no a `customers`. Cuando llama a `GetTables` con esta política, el resultado contiene únicamente las dos tablas autorizadas (la tabla `customers` no se devuelve).
------
#### [ 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"
]
}
]
}
```
------
Puede simplificar la política anterior mediante `store*` para hacer coincidir los nombres de las tablas que comienzan por `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*"
]
}
]
}
```
------
Del mismo modo, utilizando `/db1/*` para que coincida con todas las tablas de `db1`, la siguiente política concede a `GetTables` acceso a todas las tablas 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 no se proporciona un ARN de tabla, se lleva a cabo correctamente una llamada a `GetTables`, pero devuelve una lista vacía.
------
#### [ 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 el ARN de base de datos no se encuentra en la política, se produce un error con una llamada a `GetTables` con `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/*"
]
}
]
}
```
------
## Conceder acceso completo a una tabla y todas las particiones
La siguiente política concede todos los permisos a una tabla denominada `books` en la base de datos `db1`. Esto incluye permisos de lectura y escritura en la propia tabla, en las versiones archivadas de ella y en todas sus particiones.
------
#### [ 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 política anterior se puede simplificar en la práctica.
------
#### [ 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"
]
}
]
}
```
------
Tenga en cuenta que la granularidad mínima del control de acceso detallado se encuentra en el nivel de tabla. Esto significa que no puede conceder a un usuario acceso a algunas particiones de una tabla pero no a otras, o a algunas columnas de la tabla pero no a otras. Un usuario tiene acceso a toda una tabla o a nada de ella.
## Controlar el acceso mediante prefijo de nombre y denegación explícita
En este ejemplo, supongamos que las bases de datos y las tablas de su AWS Glue Data Catalog están organizadas con prefijos de nombre. Las bases de datos en la fase de desarrollo tienen el prefijo de nombre `dev-` y las que están en fase de producción tienen el prefijo de nombre `prod-`. Utilice la siguiente política para conceder a los desarrolladores acceso completo a todas las bases de datos, tablas, UDF, etc., que tengan el prefijo `dev-`. Sin embargo, debe conceder acceso de solo lectura a todo lo que incluya el prefijo `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 segunda instrucción de la política anterior utiliza explícito `deny`. Puede utilizar `deny` explícito para sobrescribir los permisos `allow` que se conceden al principal. Esto le permite bloquear el acceso a los recursos de vital importancia y evitar que otra política conceda accidentalmente acceso a ellos.
En el ejemplo anterior, aunque la primera instrucción concede acceso completo a los recursos de `prod-`, la segunda instrucción revoca explícitamente el acceso de escritura a ellos, lo que deja acceso de solo lectura a los recursos de `prod-`.
## Conceder acceso mediante etiquetas
Por ejemplo, supongamos que desea limitar el acceso de un usuario específico de la cuenta denominado `t2` a un desencadenador `Tom`. Todos los demás usuarios, entre los que se incluye `Sam`, tienen acceso para desencadenar `t1`. Los desencadenadores `t1` y `t2` tienen las siguientes propiedades.
```
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 * * ? *)"
}
]
}
```
El administrador de AWS Glue asoció un valor de etiqueta `Tom` (`aws:ResourceTag/Name": "Tom"`) al desencadenador `t2`. El administrador de AWS Glue también le proporcionó a Tom una política de IAM con una declaración de condición basada en la etiqueta. Por tanto, Tom solamente puede utilizar una operación de AWS Glue que actúe sobre los recursos con el valor de etiqueta `Tom`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "glue:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Name": "Tom"
}
}
}
]
}
```
------
Cuando Tom intenta obtener acceso al desencadenador `t1`, recibe un mensaje de acceso denegado. Sin embargo, puede recuperar correctamente el desencadenador `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 no puede usar la operación de API `GetTriggers` plural para mostrar los desencadenadores, ya que esta operación no admite el filtrado de etiquetas.
Para proporcionar a Tom acceso a `GetTriggers`, el administrador de AWS Glue crea una política que estructura los permisos en dos secciones. Una sección permite que Tom tenga acceso a todos los desencadenadores con la operación API `GetTriggers`. La segunda sección permite que Tom tenga acceso a las operaciones API etiquetadas con el valor `Tom`. Con esta política, Tom puede utilizar `GetTriggers` y `GetTrigger` para obtener acceso al desencadenador `t2`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "glue:GetTriggers",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "glue:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Name": "Tom"
}
}
}
]
}
```
------
## Denegar acceso mediante etiquetas
Otra estrategia para la política de recursos consiste en denegar el acceso a los recursos explícitamente.
**importante**
Las políticas de denegación explícita no funcionan con las operaciones de API plurales, como `GetTriggers`.
En la siguiente política de ejemplo, se permiten todas las operaciones de trabajo de AWS Glue. Sin embargo, la segunda declaración `Effect` niega *explícitamente* el acceso a los trabajos etiquetados con la clave `Team` y el valor `Special`.
Cuando un administrador asocia la siguiente política a una identidad, esta puede acceder a todos los trabajos, *excepto* los que están etiquetados con la clave `Team` y el valor `Special`.
## Usar etiquetas con las operaciones de API List y Batch
Un tercer enfoque para elaborar una política de recursos consiste en permitir el acceso a los recursos utilizando una operación API `List` que muestre los recursos de un valor de etiqueta. A continuación, se utilizará la operación API `Batch` correspondiente, que permitirá obtener acceso a los detalles de recursos específicos. Con este enfoque, el administrador no necesita permitir el acceso las operaciones API `GetCrawlers`, `GetDevEndpoints`, `GetJobs` o `GetTriggers` plurales. En su lugar, puede proporcionar la capacidad para mostrar los recursos con las siguientes operaciones API:
+ `ListCrawlers`
+ `ListDevEndpoints`
+ `ListJobs`
+ `ListTriggers`
También puede proporcionar la posibilidad de obtener detalles sobre recursos específicos con las siguientes operaciones API:
+ `BatchGetCrawlers`
+ `BatchGetDevEndpoints`
+ `BatchGetJobs`
+ `BatchGetTriggers`
Como administrador, para utilizar este enfoque, puede realizar el siguiente procedimiento:
1. Añadir etiquetas a los rastreadores, puntos de enlace de desarrollo, trabajos y desencadenadores.
1. Denegar a los usuarios el acceso a las operaciones API `Get`, como `GetCrawlers`, `GetDevEndponts`, `GetJobs` y `GetTriggers`.
1. Para que los usuarios puedan saber a qué recursos etiquetados tienen acceso, proporcióneles acceso a las operaciones API `List`, como `ListCrawlers`, `ListDevEndponts`, `ListJobs` y `ListTriggers`.
1. Denegar a los usuarios el acceso a las API de etiquetado de AWS Glue, como `TagResource` y `UntagResource`.
1. Permitir el acceso de los usuarios a los detalles de los recursos con operaciones API `BatchGet`, como `BatchGetCrawlers`, `BatchGetDevEndponts`, `BatchGetJobs` y `BatchGetTriggers`.
Por ejemplo, cuando llame a la operación `ListCrawlers`, proporcione un valor de etiqueta que coincida con el nombre de usuario. El resultado es una lista de rastreadores que coincide con los valores de etiquetas proporcionados. Proporcione la lista de nombres a `BatchGetCrawlers` para obtener información sobre cada uno de los rastreadores con la etiqueta especificada.
Por ejemplo, si Tom solo puede recuperar información sobre los desencadenadores con la etiqueta `Tom`, el administrador puede agregar etiquetas a los desencadenadores de `Tom`, denegar a todos los usuarios el acceso a la operación de API `GetTriggers` y permitir a todos los usuarios el acceso a `ListTriggers` y `BatchGetTriggers`.
A continuación, se muestra la política de recursos que al administrador de AWS Glue concede a Tom. En la primera sección de la política, todas las operaciones API de AWS Glue están denegadas para `GetTriggers`. En la segunda sección de la política, la operación API `ListTriggers` está permitida en todos los recursos. Sin embargo, en la tercera sección, los recursos con la etiqueta `Tom` tienen permitido el acceso mediante `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"
}
}
}
]
}
```
------
Si utilizamos los mismos desencadenadores que en el ejemplo anterior, Tom tendrá acceso al desencadenador `t2`, pero no al desencadenador `t1`. En el siguiente ejemplo, se muestran los resultados cuando Tom intenta obtener acceso a `t1` y `t2` con `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.
```
En el siguiente ejemplo, se muestran los resultados cuando Tom intenta obtener acceso a los desencadenadores `t2` y `t3` (que no existe) en la misma llamada a `BatchGetTriggers`. Tenga en cuenta que, como Tom tiene acceso al desencadenador `t2` y dicho desencadenador existe, solo se devuelve `t2`. Aunque Tom tenga autorización para obtener acceso al desencadenador `t3`, el desencadenador `t3` no existe, por lo que, al devolver la respuesta, `t3` estará incluido en una lista 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 * * ? *)"
}
}
```
## Controlar la configuración mediante claves de condición o claves de contexto
Puede utilizar claves de condición o claves de contexto al conceder permisos para crear y actualizar trabajos. En estas secciones, se analizan las claves:
+ [Políticas que controlan la configuración mediante claves de condición](#glue-identity-based-policy-condition-key-vpc)
+ [Políticas que controlan la configuración mediante claves de contexto](#glue-identity-based-policy-context-key-glue)
### Políticas que controlan la configuración mediante claves de condición
AWS Glue proporciona tres claves de condición de IAM: `glue:VpcIds`, `glue:SubnetIds` y `glue:SecurityGroupIds`. Puede utilizar claves de condición en políticas de IAM al conceder permisos para crear y actualizar trabajos. Puede utilizar esta configuración para asegurarse de que no se creen trabajos ni sesiones (ni se actualicen) para ejecutarse fuera del entorno de VPC deseado. La información de configuración de la VPC no es una entrada directa de la solicitud `CreateJob`, sino que se infiere del campo “conexiones” del trabajo que apunta a una conexión de AWS Glue.
**Ejemplo de uso**
Cree una conexión de tipo de red de AWS Glue denominada “traffic-monitored-connection” con el ID de la VPC deseado: “vpc-id1234”, SubnetIds y SecurityGroupIds.
Especifique la condición de las claves de condición para las acciones `CreateJob` y `UpdateJob` en la política de IAM.
```
{
"Effect": "Allow",
"Action": [
"glue:CreateJob",
"glue:UpdateJob"
],
"Resource": [
"*"
],
"Condition": {
"ForAnyValue:StringLike": {
"glue:VpcIds": [
"vpc-id1234"
]
}
}
}
```
Puede establecer una política de IAM similar para prohibir la creación de un trabajo de AWS Glue sin especificar información de conexión.
**Restricción de sesiones en las VPC**
Para hacer que las sesiones creadas se ejecuten en una VPC específica, debe restringir el permiso del rol al agregar un efecto `Deny` a la acción `glue:CreateSession` con la condición de que glue:vpc-id no sea igual a vpc-<123>. Por ejemplo:
```
"Effect": "Deny",
"Action": [
"glue:CreateSession"
],
"Condition": {
"StringNotEquals" : {"glue:VpcIds" : ["vpc-123"]}
}
```
También puede hacer que las sesiones creadas se ejecuten en una VPC al agregar un `Deny` efecto en la `glue:CreateSession` acción con la condición de que `glue:vpc-id` sea nulo. Por ejemplo:
```
{
"Effect": "Deny",
"Action": [
"glue:CreateSession"
],
"Condition": {
"Null": {"glue:VpcIds": true}
}
},
{
"Effect": "Allow",
"Action": [
"glue:CreateSession"
],
"Resource": ["*"]
}
```
### Políticas que controlan la configuración mediante claves de contexto
AWS Glue proporciona una clave de contexto (`glue:CredentialIssuingService= glue.amazonaws.com`) a cada sesión de rol que AWS Glue pone a disposición del punto de conexión del trabajo y del desarrollador. Esto le permite implementar controles de seguridad para las acciones llevadas a cabo por scripts de AWS Glue. AWS Glue proporciona otra clave de contexto (`glue:RoleAssumedBy=glue.amazonaws.com`) a cada sesión de rol en la que AWS Glue realice una llamada a otro servicio de AWS en nombre del cliente (no mediante un punto de conexión del trabajo o el desarrollador, sino directamente mediante el servicio de AWS Glue).
**Ejemplo de uso**
Especifique el permiso condicional en una política de IAM y asócielo al rol que utilizará un trabajo de AWS Glue. Esto garantiza que se permitan o denieguen determinadas acciones en función de si la sesión de rol se utiliza para el entorno de tiempo de ejecución de un trabajo de AWS Glue.
```
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringEquals": {
"glue:CredentialIssuingService": "glue.amazonaws.com"
}
}
}
```
## Cómo denegar a una identidad la capacidad de crear sesiones de vista previa de datos
En esta sección, se incluye un ejemplo de política de IAM que se usa para denegar a una identidad la capacidad de crear sesiones de vista previa de datos. Adjunte esta política a la identidad, que es independiente del rol que se usa en la sesión de vista previa de datos durante su ejecución.
```
{
"Sid": "DatapreviewDeny",
"Effect": "Deny",
"Action": [
"glue:CreateSession"
],
"Resource": [
"arn:aws:glue:*:*:session/glue-studio-datapreview*"
]
}
```