Exemplos de políticas baseadas em identidade para Glue AWS

Por padrão, usuários e funções não têm permissão para criar ou modificar recursos do AWS Glue. Eles também não podem realizar tarefas usando o AWS Management Console, AWS Command Line Interface (AWS CLI) ou AWS API. Para conceder permissão aos usuários para realizar ações nos recursos de que precisam, um IAM administrador pode criar IAM políticas. O administrador pode então adicionar as IAM políticas às funções e os usuários podem assumir as funções.

Para saber como criar uma política IAM baseada em identidade usando esses exemplos de documentos de JSON política, consulte Criar IAM políticas (console) no Guia do IAMusuário.

Para obter detalhes sobre ações e tipos de recursos definidos pelo AWS Glue, incluindo o formato de cada um dos tipos de recursos, consulte Ações, recursos e chaves de condição do AWS Glue na Referência de Autorização de Serviço. ARNs

Melhores práticas de política

As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do AWS Glue em sua conta. Essas ações podem incorrer em custos para seus Conta da AWS. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações:

Para obter mais informações sobre as melhores práticas emIAM, consulte as melhores práticas de segurança IAM no Guia IAM do usuário.

As permissões em nível de recurso só se aplicam a permissões específicas AWS Glue objects

Você só pode definir um controle refinado para objetos específicos no AWS Glue. Portanto, você deve escrever a IAM política do seu cliente para que API as operações que permitem Amazon Resource Names (ARNs) para a Resource declaração não sejam misturadas com API operações que não permitemARNs.

Por exemplo, a IAM política a seguir permite API operações para GetClassifier GetJobRun e. Ele define o Resource como * porque AWS Glue não permite ARNs classificadores e execuções de trabalhos. Porque ARNs são API permitidas operações específicas, como GetDatabase eGetTable, ARNs podem ser especificadas na segunda metade da 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 uma lista de AWS Glue objetos que permitemARNs, vejaEspecificar ARNs de recursos do AWS Glue.

Usando o console AWS Glue

Para acessar o console AWS Glue, você deve ter um conjunto mínimo de permissões. Essas permissões devem permitir que você liste e visualize detalhes sobre os recursos do AWS Glue em seu Conta da AWS. Caso crie uma política baseada em identidade mais restritiva que as permissões mínimas necessárias, o console não funcionará como pretendido para entidades (usuários ou perfis) com essa política.

Você não precisa permitir permissões mínimas do console para usuários que estão fazendo chamadas somente para AWS CLI o. ou AWS API o. Em vez disso, permita o acesso somente às ações que correspondam à API operação que eles estão tentando realizar.

Para garantir que usuários e funções ainda possam usar o console do AWS Glue, anexe também o AWS Glue ConsoleAccess ou a política ReadOnly AWS gerenciada às entidades. Para obter mais informações, consulte Adicionar permissões a um usuário no Guia do IAM usuário.

Para que um usuário trabalhe com o AWS Glue console, esse usuário deve ter um conjunto mínimo de permissões que permita trabalhar com o AWS Glue recursos para sua AWS conta. Além desses AWS Glue permissões, o console exige permissões dos seguintes serviços:

Para obter mais informações sobre as permissões que os usuários precisam para visualizar e trabalhar com o AWS Glue console, vejaEtapa 3: anexar uma política aos usuários ou grupos que acessam o AWS Glue.

Se você criar uma IAM política que seja mais restritiva do que as permissões mínimas exigidas, o console não funcionará conforme o esperado para os usuários com essa IAM política. Para garantir que esses usuários ainda possam usar o AWS Glue console, anexe também a política AWSGlueConsoleFullAccess gerenciada conforme descrito emPolíticas gerenciadas pela AWS (predefinidas) para o AWS Glue.

Permitir que usuários visualizem suas próprias permissões

Este exemplo mostra como você pode criar uma política que permita IAM aos usuários visualizar as políticas embutidas e gerenciadas que estão anexadas à identidade do usuário. Essa política inclui permissões para concluir essa ação no console ou programaticamente usando o AWS CLI ou. AWS API

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

Conceder permissões somente de leitura para uma tabela

A política a seguir concede permissão somente leitura a uma tabela books no banco de dados db1. Para obter mais informações sobre o recurso Amazon Resource Names (ARNs), consulteARNs do 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"
      ]
    }
  ]
}

Essa política concede permissão somente leitura a uma tabela chamada books no banco de dados chamado db1. Para conceder a permissão Get para uma tabela, também é necessário conceder permissão para os recursos do catálogo e do banco de dados.

A política a seguir concede as permissões mínimas necessárias para um criar a tabela tb1 no banco de dados 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 tabelas por GetTables permissão

Suponha que há três tabelas: customers, stores e store_sales no banco de dados db1. A política a seguir concede a permissão GetTables a stores e store_sales, mas não a customers. Quando você chama GetTables com essa política, o resultado contém somente as duas tabelas autorizadas (a tabela customers não é retornada).

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

Você pode simplificar a política anterior usando store* para corresponder a todos os nomes de tabelas que comecem com 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*"
            ]
        }
    ]
}

Da mesma forma, usando /db1/* para corresponder a todas as tabelas no db1, a política a seguir concede o acesso GetTables a todas as tabelas no 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/*"
            ]
        }
    ]
}

Se nenhuma tabela ARN for fornecida, uma chamada para GetTables será bem-sucedida, mas ela retornará uma lista vazia.

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

Se o banco de dados ARN estiver ausente na política, uma chamada para GetTables falhará com umAccessDeniedException.

{
    "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 total acesso a uma tabela e a todas as partições

A política a seguir concede todas as permissões em uma tabela denominada books no banco de dados db1. Isso inclui permissões de leitura e gravação na própria tabela, em versões arquivadas da tabela e em todas as suas partições.

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

A política anterior pode ser simplificada na prática.

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

Observe que a granularidade mínima de um controle de acesso granular é no nível de tabela. Isso significa que você não pode conceder a um usuário acesso a algumas partições em uma tabela, mas não a outras, ou a algumas colunas da tabela, mas não a outras. Um usuário tem acesso a tudo ou a nada de uma tabela.

Controlar acesso por prefixo de nome e negação explícita

Neste exemplo, suponha que os bancos de dados e tabelas em seu AWS Glue Data Catalog estejam organizados usando prefixos de nome. Os bancos de dados no estágio de desenvolvimento têm o prefixo de nome dev-, e os em produção têm o prefixo de nome prod-. Você pode usar a política a seguir para conceder aos desenvolvedores acesso total a todos os bancos de dadosUDFs, tabelas etc. que tenham o dev- prefixo. Mas você concede acesso somente leitura a tudo com o prefixo 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-*"
            ]
        }
    ]
}

A segunda instrução na política anterior usa deny explícita. Você pode usar deny explícita para substituir todas as permissões allow que foram concedidas à entidade principal. Isso permite bloquear o acesso a recursos críticos e impedir que outra política conceda acesso a eles acidentalmente.

No exemplo anterior, embora a primeira instrução conceda acesso total aos recursos prod-, a segunda instrução revoga explicitamente o acesso de gravação neles, deixando apenas o acesso de leitura aos recursos prod-.

Conceder acesso usando tags

Por exemplo, suponha que você deseja limitar o acesso a um gatilho t2 para um usuário específico chamado Tom em sua conta. Todos os outros usuários, inclusive Sam, têm acesso ao gatilho t1. Os gatilhos t1 e t2 têm as seguintes propriedades.

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 * * ? *)"
        }
    ]
}

A ferramenta AWS Glue O administrador anexou um valor de tag Tom (aws:ResourceTag/Name": "Tom") para acionart2. A ferramenta AWS Glue O administrador também deu a Tom uma IAM política com uma declaração de condição baseada na etiqueta. Como resultado, Tom só pode usar um AWS Glue operação que atua em recursos com o valor da tagTom.

{
    "Version": "2012-10-17",
    "Statement": [
        {
         "Effect": "Allow",
         "Action": "glue:*",
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                "aws:ResourceTag/Name": "Tom"
              }
          }
         }
    ]
}

Quando Tom tentar acessar o gatilho t1, ele receberá uma mensagem de acesso negado. Enquanto isso, ele pode recuperar o gatilho t2 com êxito.

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 não pode usar a GetTriggers API operação plural para listar gatilhos porque essa operação não suporta filtragem em tags.

Para dar acesso a TomGetTriggers, o AWS Glue O administrador cria uma política que divide as permissões em duas seções. Uma seção permite que Tom acesse todos os gatilhos da GetTriggers API operação. A segunda seção permite que Tom acesse API as operações marcadas com o valorTom. Com essa política, Tom tem permissão de acesso a GetTriggers e GetTrigger para o gatilho t2.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "glue:GetTriggers",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "glue:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Name": "Tom"
                }
            }
        }
    ]
}

Negar acesso usando tags

Outra abordagem de uma política de recurso é negar explicitamente o acesso aos recursos.

No exemplo de política a seguir, todos AWS Glue operações de trabalho são permitidas. Porém, a segunda instrução Effect nega explicitamente acesso a trabalhos marcados com a chave Team e o valor Special.

Quando um administrador anexa a política a seguir a uma identidade, essa entidade pode acessar todos os trabalhos, exceto os marcados com a chave Team e o 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"
        }
      }
    }
  ]
}

Use tags com API operações de lista e lote

Uma terceira abordagem para escrever uma política de recursos é permitir o acesso aos recursos usando uma List API operação para listar recursos para um valor de tag. Em seguida, use a Batch API operação correspondente para permitir o acesso aos detalhes de recursos específicos. Com essa abordagem, o administrador não precisa permitir o acesso ao pluralGetCrawlers,, GetDevEndpointsGetJobs, ou GetTriggers API operações. Em vez disso, você pode permitir a possibilidade de listar os recursos com as seguintes API operações:

Além disso, você pode permitir a obtenção de detalhes sobre recursos individuais com as seguintes API operações:

Como administrador, para usar essa abordagem, faça o seguinte:

Por exemplo, ao chamar a operação ListCrawlers, forneça um valor de tag de acordo com o nome do usuário. O resultado será uma lista de crawlers que correspondem aos valores de tag fornecidos. Forneça a lista de nomes ao BatchGetCrawlers para obter detalhes sobre cada crawler com a tag dada.

Por exemplo, se Tom só conseguir recuperar detalhes dos gatilhos marcados comTom, o administrador pode adicionar tags aos gatilhos paraTom, negar o acesso à GetTriggers API operação a todos os usuários e permitir o acesso de todos os usuários à e. ListTriggers BatchGetTriggers

A seguir está a política de recursos que o AWS Glue o administrador concede a Tom. Na primeira seção da política, AWS Glue APIas operações são negadas porGetTriggers. Na segunda seção da política, ListTriggers é permitida para todos os recursos. No entanto, na terceira seção, esses recursos marcados com Tom têm o acesso permitido com o acesso a 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"
                }
            }
        }
    ]
}

Usando os mesmos gatilhos do exemplo anterior, Tom pode acessar o gatilho t2, mas não o gatilho t1. O exemplo a seguir mostra os resultados quando Tom tenta acessar t1 e t2 com 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.

O exemplo a seguir mostra os resultados quando Tom tenta acessar ambos os gatilhos t2 e t3 (que não existe) na mesma chamada de BatchGetTriggers. Observe que, como Tom tem acesso ao gatilho t2 e ele existe, somente t2 é retornado. Embora Tom tenha permissão para acessar o gatilho t3, t3 não existe, de modo que t3 é retornado na resposta em uma 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 as configurações usando chaves de condição ou chaves de contexto

Você pode usar chaves de condição ou chaves de contexto ao conceder permissões para criar e atualizar trabalhos. Estas seções discutem as chaves:

Controlar políticas que controlam configurações usando chaves de condição

AWS Glue fornece três chaves de IAM condição glue:VpcIdsglue:SubnetIds, glue:SecurityGroupIds e. Você pode usar as chaves de condição nas IAM políticas ao conceder permissões para criar e atualizar trabalhos. Você pode usar essa configuração para garantir que trabalhos ou sessões não sejam criados (ou atualizados) para serem executados fora do VPC ambiente desejado. As informações de VPC configuração não são uma entrada direta da CreateJob solicitação, mas inferidas do campo “conexões” do trabalho que aponta para um AWS Glue conexão.

Exemplo de uso

Crie um AWS Glue tipo de conexão de rede chamada "traffic-monitored-connection" com o VpcId “vpc-id1234" desejado, e. SubnetIds SecurityGroupIds

Especifique a condição das chaves de condição para a UpdateJob ação CreateJob e na IAM política.

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

Você pode criar uma IAM política semelhante para proibir a criação de um AWS Glue trabalho sem especificar informações de conexão.

Restringindo sessões em VPCs

<123>Para impor que as sessões criadas sejam executadas dentro de uma função especificadaVPC, você restringe a permissão da função adicionando um Deny efeito na glue:CreateSession ação com a condição de que o glue:vpc-id não seja igual a vpc-. Por exemplo:

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

Você também pode impor que as sessões criadas sejam executadas em um VPC adicionando um Deny efeito na glue:CreateSession ação com a condição de que glue:vpc-id seja nulo. Por exemplo:

{
    "Effect": "Deny",
    "Action": [
        "glue:CreateSession"
    ],
      "Condition": {
        "Null": {"glue:VpcIds": true}
    }
}, 
{
    "Effect": "Allow",
    "Action": [
        "glue:CreateSession"
    ],
    "Resource": ["*"]
}             
               

Controlar políticas que controlam configurações usando chaves de contexto

AWS Glue fornece uma chave de contexto (glue:CredentialIssuingService= glue.amazonaws.com) para cada sessão de função que AWS Glue disponibiliza para o terminal do trabalho e do desenvolvedor. Isso permite que você implemente controles de segurança para as ações tomadas pelo AWS Glue scripts. AWS Glue fornece outra chave de contexto (glue:RoleAssumedBy=glue.amazonaws.com) para cada sessão de função em que AWS Glue faz uma chamada para outro AWS serviço em nome do cliente (não por um endpoint de trabalho/desenvolvimento, mas diretamente pelo AWS Glue serviço).

Exemplo de uso

Especifique a permissão condicional em uma IAM política e anexe-a à função a ser usada por um AWS Glue emprego. Isso garante que determinadas ações sejam permitidas/negadas com base no fato de a sessão de função ser usada para um AWS Glue ambiente de execução do trabalho.

{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::confidential-bucket/*",
    "Condition": {
        "StringEquals": {
            "glue:CredentialIssuingService": "glue.amazonaws.com"
        }
    }
}

Negação da capacidade de criar sessões de pré-visualização de dados para uma identidade

Esta seção contém um exemplo IAM de política usado para negar a uma identidade a capacidade de criar sessões de visualização de dados. Anexe essa política à identidade, que é separada do perfil usado pela sessão de pré-visualização de dados durante sua execução.

{
    "Sid": "DatapreviewDeny",
    "Effect": "Deny",
     "Action": [
           "glue:CreateSession"
     ],
     "Resource": [
          "arn:aws:glue:*:*:session/glue-studio-datapreview*"
      ]
 }