Ejemplos de políticas basadas en identidades para AWS Glue - AWS Adherencia
Prácticas recomendadas sobre las políticasLimitaciones de autorización de nivel de recursosMediante la consolaCómo permitir a los usuarios consultar sus propios permisosAcceso de tabla de solo lecturaFiltrar tablasAcceso completo a la tablaPrefijo de nombre con denegaciónEjemplo de control de acceso mediante etiquetasDenegar acceso mediante etiquetasUsar etiquetas con las operaciones de API List y BatchCrear políticas que controlan la configuración mediante claves de condiciónCómo denegar a una identidad la capacidad de crear sesiones de vista previa de datos

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

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. Tampoco pueden realizar tareas mediante la AWS Management Console, la AWS Command Line Interface (AWS CLI) o la API de AWS. Un administrador de IAM puede crear políticas de IAM para conceder permisos a los usuarios para realizar acciones en los recursos que necesitan. A continuación, el administrador puede agregar las políticas de IAM a los roles, y los usuarios pueden asumirlos.

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 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 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.

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 costes adicionales para su Cuenta de AWS. Siga estas directrices y recomendaciones al crear o editar políticas basadas en identidades:

  • Comience con las políticas administradas por AWSy continúe con los permisos de privilegio mínimo: a fin de comenzar a conceder permisos a los usuarios y las cargas de trabajo, utilice las políticas administradas por AWS, que conceden 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 o las políticas administradas por AWS para funciones de trabajo 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 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 AWS CloudFormation. Para obtener más información, consulte Elementos de la política de JSON de IAM: Condición en la Guía del usuario de IAM.

  • Utilice 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 Política de validación de Analizador de acceso de IAM en la Guía de usuario de IAM.

  • Solicite la autenticación multifactor (MFA): si se encuentra en una situación en la que necesita usuarios raíz o de IAM en su Cuenta de AWS, active la MFA para mayor seguridad. Para solicitar la MFA cuando se invocan las operaciones de la API, agregue las condiciones de la MFA a sus políticas. Para más información, consulte Configuración del acceso a una API protegido por MFA en la Guía de usuario de IAM.

Para obtener más información sobre las prácticas recomendadas de IAM, consulte las Prácticas recomendadas de seguridad en IAM 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.

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

Para ver una lista de objetos de AWS Glue que permiten el uso de ARN, consulte Especificar AWS Glue el recurso ARNs.

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 que conceda 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, permite 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 más información, consulte Adición de permisos a un usuario 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.

  • Permisos de AWS Identity and Access Management (IAM) para enumerar y transferir roles.

  • Permisos AWS CloudFormation 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.

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 Políticas administradas (predefinidas) por AWS para AWS Glue.

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 Catálogo de datos 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"
      ]
    }
  ]
}

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:

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

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).

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

Puede simplificar la política anterior mediante store* para hacer coincidir los nombres de las tablas que comienzan por 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*"
            ]
        }
    ]
}

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.

{
    "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 no se proporciona un ARN de tabla, se lleva a cabo correctamente una llamada a GetTables, pero devuelve una lista vacía.

{
    "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 el ARN de base de datos no se encuentra en la política, se produce un error con una llamada a GetTables con AccessDeniedException.

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

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.

{
    "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 política anterior se puede simplificar en la práctica.

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

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-.

{
    "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 segunda instrucción de la política anterior utiliza deny explícito. 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 Tom a un desencadenador t2. 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. 

{
    "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. 

{
    "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. 

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

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.

  2. Denegar a los usuarios el acceso a las operaciones API Get, como GetCrawlers, GetDevEndponts, GetJobs y GetTriggers.

  3. 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.

  4. Denegar a los usuarios el acceso a las API de etiquetado de AWS Glue, como TagResource y UntagResource.

  5. 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. 

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

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