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
nota
Todos os exemplos fornecidos nesta seção usam a região us-west-2
. Você pode substituí-lo pela AWS região que deseja usar.
Tópicos
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:
-
Comece com as políticas AWS gerenciadas e avance para as permissões de privilégios mínimos — Para começar a conceder permissões aos seus usuários e cargas de trabalho, use as políticas AWS gerenciadas que concedem permissões para muitos casos de uso comuns. Eles estão disponíveis no seu Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo AWS cliente que sejam específicas para seus casos de uso. Para obter mais informações, consulte políticas AWS gerenciadas ou políticas AWS gerenciadas para funções de trabalho no Guia IAM do usuário.
-
Aplique permissões com privilégios mínimos — Ao definir permissões com IAM políticas, conceda somente as permissões necessárias para realizar uma tarefa. Você faz isso definindo as ações que podem ser executadas em atributos específicos sob condições específicas, também conhecidas como permissões de privilégio mínimo. Para obter mais informações sobre IAM como usar para aplicar permissões, consulte Políticas e permissões IAM no Guia IAM do usuário.
-
Use condições nas IAM políticas para restringir ainda mais o acesso — Você pode adicionar uma condição às suas políticas para limitar o acesso a ações e recursos. Por exemplo, você pode escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usandoSSL. Você também pode usar condições para conceder acesso às ações de serviço se elas forem usadas por meio de uma ação específica AWS service (Serviço da AWS), como AWS CloudFormation. Para obter mais informações, consulte elementos IAM JSON da política: Condição no Guia IAM do usuário.
-
Use o IAM Access Analyzer para validar suas IAM políticas e garantir permissões seguras e funcionais — o IAM Access Analyzer valida políticas novas e existentes para que as políticas sigam a linguagem da IAM política (JSON) e as melhores práticas. IAM IAMO Access Analyzer fornece mais de 100 verificações de políticas e recomendações práticas para ajudá-lo a criar políticas seguras e funcionais. Para obter mais informações, consulte Validar políticas com o IAM Access Analyzer no Guia do IAMUsuário.
-
Exigir autenticação multifatorial (MFA) — Se você tiver um cenário que exija IAM usuários ou um usuário root Conta da AWS, ative MFA para obter segurança adicional. Para exigir MFA quando API as operações são chamadas, adicione MFA condições às suas políticas. Para obter mais informações, consulte APIAcesso seguro MFA no Guia do IAM usuário.
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
ou a política ConsoleAccess
AWS gerenciada às entidades. Para obter mais informações, consulte Adicionar permissões a um usuário no Guia do IAM usuário.ReadOnly
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:
-
Permissões do Amazon CloudWatch Logs para exibir registros.
-
AWS Identity and Access Management (IAM) permissões para listar e passar funções.
-
AWS CloudFormation permissões para trabalhar com pilhas.
-
Permissões do Amazon Elastic Compute Cloud (AmazonEC2) para listasVPCs, sub-redes, grupos de segurança, instâncias e outros objetos.
-
Permissões do Amazon Simple Storage Service (Amazon S3) para listar buckets e objetos e para recuperar e salvar scripts.
-
Permissões do Amazon Redshift necessárias para trabalhar com clusters.
-
Permissões do Amazon Relational Database Service (RDSAmazon) para listar instâncias.
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.
Importante
Uma política de negação explícita não funciona para API operações plurais, como. GetTriggers
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
,, GetDevEndpoints
GetJobs
, ou GetTriggers
API operações. Em vez disso, você pode permitir a possibilidade de listar os recursos com as seguintes API operações:
-
ListCrawlers
-
ListDevEndpoints
-
ListJobs
-
ListTriggers
Além disso, você pode permitir a obtenção de detalhes sobre recursos individuais com as seguintes API operações:
-
BatchGetCrawlers
-
BatchGetDevEndpoints
-
BatchGetJobs
-
BatchGetTriggers
Como administrador, para usar essa abordagem, faça o seguinte:
-
Adicionar tags a seus crawlers, endpoints de desenvolvimento, trabalhos e gatilhos.
-
Negar o acesso do usuário a
Get
API operações comoGetCrawlers
GetDevEndponts
GetJobs
,,GetTriggers
e. -
Para permitir que os usuários descubram a quais recursos marcados eles têm acesso, permita que o usuário acesse
List
API operações comoListCrawlers
ListDevEndponts
ListJobs
,,ListTriggers
e. -
Negar o acesso do usuário ao AWS Glue marcaçãoAPIs, como
TagResource
e.UntagResource
-
Permita que o usuário acesse os detalhes dos recursos com
BatchGet
API operações comoBatchGetCrawlers
BatchGetDevEndponts
BatchGetJobs
,,BatchGetTriggers
e.
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:VpcIds
glue: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*" ] }