Ejemplos de políticas basadas en la identidad para Glue AWS - AWS Glue
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 etiquetasUtilice etiquetas con las API operaciones de listas y lotesCrear 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

Ejemplos de políticas basadas en la identidad para Glue AWS

De forma predeterminada, los usuarios y los roles no tienen permiso para crear o modificar los recursos de AWS Glue. Tampoco pueden realizar tareas con AWS Management Console, AWS Command Line Interface (AWS CLI) o AWS API. Para conceder a los usuarios permiso para realizar acciones en los recursos que necesitan, un IAM administrador puede crear IAM políticas. A continuación, el administrador puede añadir las IAM políticas a las funciones y los usuarios pueden asumir las funciones.

Para obtener información sobre cómo crear una política IAM basada en la identidad mediante estos documentos de JSON política de ejemplo, consulte Crear IAM políticas (consola) en la Guía del IAMusuario.

Para obtener más información sobre las acciones y los tipos de recursos definidos por AWS Glue, incluido el ARNs formato de cada uno de los tipos de recursos, consulte Acciones, recursos y claves de condición de AWS Glue en la referencia de autorización del servicio.

nota

Todos los ejemplos que se proporcionan en esta sección utilizan la región us-west-2. Puedes sustituirla por la AWS región que quieras usar.

Prácticas recomendadas sobre las políticas

Las políticas basadas en la identidad determinan si alguien puede crear recursos de AWS Glue de tu cuenta, acceder a ellos o eliminarlos. Estas acciones puedes 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 AWS administradas y avance hacia los permisos con privilegios mínimos: para empezar a conceder permisos a sus usuarios y cargas de trabajo, utilice las políticas AWS administradas que otorgan permisos para muchos casos de uso comunes. Están disponibles en su. Cuenta de AWS Le recomendamos que reduzca aún más los permisos definiendo políticas administradas por el AWS cliente que sean específicas para sus casos de uso. Para obtener más información, consulte las políticas AWS gestionadas o las políticas AWS gestionadas para las funciones laborales en la Guía del IAM usuario.

  • Aplique permisos con privilegios mínimos: cuando establezca permisos con IAM políticas, conceda solo los permisos necesarios para realizar una tarea. Para ello, debe definir las acciones que se puedes llevar a cabo en determinados recursos en condiciones específicas, también conocidos como permisos de privilegios mínimos. Para obtener más información sobre cómo IAM aplicar permisos, consulte Políticas y permisos IAM en la IAM Guía del usuario.

  • Utilice las condiciones en IAM las políticas para restringir aún más el acceso: puede añadir 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ítica para especificar que todas las solicitudes deben enviarse medianteSSL. También puedes usar condiciones para conceder el acceso a las acciones del servicio si se utilizan a través de una acción específica Servicio de AWS, por ejemplo AWS CloudFormation. Para obtener más información, consulte los elementos IAM JSON de la política: Condición en la Guía del IAM usuario.

  • Utilice IAM Access Analyzer para validar sus IAM políticas y garantizar permisos seguros y funcionales: IAM Access Analyzer valida las políticas nuevas y existentes para que se ajusten al lenguaje de las políticas (JSON) y IAM a las IAM mejores prácticas. IAMAccess Analyzer proporciona más de 100 comprobaciones de políticas y recomendaciones prácticas para ayudarle a crear políticas seguras y funcionales. Para obtener más información, consulte Validar políticas con IAM Access Analyzer en la Guía del IAM usuario.

  • Requerir autenticación multifactorial (MFA): si se encuentra en una situación en la que se requieren IAM usuarios o un usuario raíz Cuenta de AWS, actívela MFA para aumentar la seguridad. Para solicitarlo MFA cuando se convoque a API las operaciones, añada MFA condiciones a sus políticas. Para obtener más información, consulte APIAcceso seguro con MFA en la Guía del IAM usuario.

Para obtener más información sobre las prácticas recomendadasIAM, consulte las prácticas recomendadas de seguridad IAM en la Guía del IAM usuario.

Los permisos a nivel de recursos solo se aplican a determinados AWS Glue objects

Solo puede definir un control detallado para objetos específicos en AWS Glue. Por lo tanto, debe redactar la IAM política de su cliente de forma que API las operaciones que permiten utilizar Amazon Resource Names (ARNs) para la Resource declaración no se mezclen con API operaciones que no lo permitenARNs.

Por ejemplo, la siguiente IAM política permite realizar API operaciones para GetClassifier yGetJobRun. Define el Resource como * porque AWS Glue no permite la utilización ARNs de clasificadores ni la ejecución de tareas. Porque ARNs están permitidos para API operaciones específicas, como GetDatabase yGetTable, se ARNs pueden especificar 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 obtener una lista de AWS Glue objetos que lo permitenARNs, consulteEspecificación de ARN del recurso de AWS Glue.

Uso de la consola AWS Glue

Para acceder a la consola AWS Glue, debe tener un conjunto mínimo de permisos. Estos permisos deben permitirte enumerar y ver detalles sobre los recursos de AWS Glue que tienes 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 concedas permisos mínimos de consola a los usuarios que solo realicen llamadas al AWS CLI o al AWS API. En su lugar, permita el acceso únicamente a las acciones que coincidan con la API operación que están intentando realizar.

Para garantizar que los usuarios y los roles puedan seguir utilizando la consola de AWS Glue, adjunte también la política de AWS Glue ConsoleAccess o ReadOnly AWS gestionada a las entidades. Para obtener más información, consulta Cómo añadir permisos a un usuario en la Guía del IAM usuario.

Para que un usuario trabaje con AWS Glue consola, ese usuario debe tener un conjunto mínimo de permisos que le permita trabajar con AWS Glue recursos para su AWS cuenta. Además de estos AWS Glue permisos, la consola requiere permisos de los siguientes servicios:

  • Permisos CloudWatch de Amazon Logs para mostrar los registros.

  • AWS Identity and Access Management (IAM) permisos para enumerar y transferir funciones.

  • AWS CloudFormation permisos para trabajar con pilas.

  • Permisos de Amazon Elastic Compute Cloud (AmazonEC2) para listasVPCs, 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 (RDSAmazon) para enumerar instancias.

Para obtener más información sobre los permisos que los usuarios necesitan para ver y trabajar con AWS Glue consola, consultePaso 3: Adjuntar una política a los usuarios o los grupos que accedan a AWS Glue.

Si creas una IAM política que sea más restrictiva que los permisos mínimos requeridos, la consola no funcionará según lo previsto para los usuarios con esa IAM política. Para garantizar que esos usuarios puedan seguir utilizando la AWS Glue consola, adjunte también la política AWSGlueConsoleFullAccess gestionada tal y como se describe enPolí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 se puede crear una política que permita a IAM los usuarios ver las políticas integradas y administradas asociadas a su identidad de usuario. Esta política incluye permisos para completar esta acción en la consola o mediante programación mediante la tecla o. AWS CLI AWS API

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}

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 el recurso Amazon Resource Names (ARNs), consulteARN de Data Catalog.

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

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 ARN se proporciona ninguna tabla, la llamada a GetTables se realiza correctamente, 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 la política no ARN incluye la base de datos, se produce un GetTables error en la llamada a. 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 del catálogo de datos de AWS Glue están organizadas mediante prefijos de nombres. 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-. Puedes usar la siguiente política para conceder a los desarrolladores acceso total a todas las bases de datos, tablasUDFs, etc., que tengan el dev- prefijo. 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 * * ? *)"
        }
    ]
}

La AWS Glue el administrador adjuntó un valor de etiqueta Tom (aws:ResourceTag/Name": "Tom") para t2 activarlo. La AWS Glue el administrador también le dio a Tom una IAM política con una declaración de condición basada en la etiqueta. Como resultado, Tom solo puede usar un AWS Glue operación que actúa sobre los recursos con el valor de la etiquetaTom. 

{
    "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 GetTriggers API operación plural para enumerar los activadores porque esta operación no admite el filtrado de etiquetas.

Para dar acceso a Tom aGetTriggers, el AWS Glue el administrador crea una política que divide los permisos en dos secciones. Una sección permite a Tom acceder a todos los factores desencadenantes de la GetTriggers API operación. La segunda sección permite a Tom acceder a API las operaciones etiquetadas con el valorTom. 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

Una política de denegación explícita no funciona para API operaciones en plural, comoGetTriggers.

En el siguiente ejemplo de política, todas AWS Glue las operaciones de trabajo están permitidas. 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"
        }
      }
    }
  ]
}

Utilice etiquetas con las API operaciones de listas y lotes

Un tercer enfoque para redactar una política de recursos consiste en permitir el acceso a los recursos mediante una List API operación para enumerar los recursos con un valor de etiqueta. A continuación, utilice la Batch API operación correspondiente para permitir el acceso a los detalles de recursos específicos. Con este enfoque, el administrador no necesita permitir el acceso a las GetTriggers API operaciones en plural GetCrawlers GetDevEndpointsGetJobs,, o. En su lugar, puedes permitir la posibilidad de enumerar los recursos con las siguientes API operaciones:

  • ListCrawlers

  • ListDevEndpoints

  • ListJobs

  • ListTriggers

Además, puedes habilitar la posibilidad de obtener detalles sobre los recursos individuales con las siguientes API operaciones:

  • 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. Denegue el acceso de los usuarios a Get API operaciones como GetCrawlersGetDevEndponts,GetJobs, yGetTriggers.

  3. Para que los usuarios puedan averiguar a qué recursos etiquetados tienen acceso, permita que los usuarios accedan a List API operaciones como ListCrawlersListDevEndponts,ListJobs, yListTriggers.

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

  5. Permita que el usuario acceda a los detalles de los recursos con BatchGet API operaciones como BatchGetCrawlersBatchGetDevEndponts,BatchGetJobs, yBatchGetTriggers.

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 debe poder recuperar los detalles de los activadores que estén etiquetadosTom, el administrador puede añadir etiquetas a los activadoresTom, denegar el acceso a la GetTriggers API operación a todos los usuarios y permitir el acceso a todos los usuarios a ListTriggers yBatchGetTriggers.

La siguiente es la política de recursos que aplica AWS Glue el administrador le otorga a Tom. En la primera sección de la política, AWS Glue APIse deniegan las operacionesGetTriggers. 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 IAM estado glue:VpcIdsglue:SubnetIds, yglue:SecurityGroupIds. Puede usar las claves de condición en IAM las políticas al conceder permisos para crear y actualizar trabajos. Puede usar esta configuración para asegurarse de que los trabajos o las sesiones no se creen (ni se actualicen) para ejecutarse fuera del VPC entorno deseado. La información de VPC configuración no proviene directamente de la CreateJob solicitud, sino que se deduce del campo de «conexiones» del trabajo que apunta a un AWS Glue conexión.

Ejemplo de uso

Crea un AWS Glue conexión de tipo de red denominada traffic-monitored-connection "» con el VpcId «vpc-id1234" deseado, y. SubnetIds SecurityGroupIds

Especifique las claves de condición, la condición CreateJob y la UpdateJob acción de la política. IAM

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

Puede crear una IAM política similar para prohibir la creación de una AWS Glue trabajo sin especificar la información de conexión.

Restringir las sesiones en VPCs

<123>Para hacer que las sesiones creadas se ejecuten dentro de un VPC espacio específico, restringe el permiso del rol añadiendo un Deny efecto a la glue:CreateSession acción con la condición de que glue:vpc-id no sea igual a vpc-. Por ejemplo: 

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

También puedes hacer que las sesiones creadas se ejecuten dentro de a VPC añadiendo un Deny efecto a la glue:CreateSession acción con la condición de que sea nulo. glue:vpc-id 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) para cada sesión de rol que AWS Glue pone a disposición del puesto de trabajo y del desarrollador. Esto le permite implementar controles de seguridad para las acciones emprendidas por AWS Glue guiones. AWS Glue proporciona otra clave de contexto (glue:RoleAssumedBy=glue.amazonaws.com) a cada sesión de rol donde AWS Glue hace una llamada a otro AWS servicio en nombre del cliente (no desde un punto final de trabajo o desarrollo, sino directamente desde el AWS Glue servicio).

Ejemplo de uso

Especifique el permiso condicional en una IAM política y adjúntelo a la función que utilizará un AWS Glue trabajo. Esto garantiza que se permitan o denieguen determinadas acciones en función de si la sesión de rol se utiliza para un AWS Glue entorno de ejecución de tareas.

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

Esta sección contiene un ejemplo IAM de política que se utiliza para denegar a una identidad la posibilidad 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*"
      ]
 }