# Exemplos de política de controle de acesso do AWS Glue
Esta seção contém exemplos de políticas de controle de acesso baseadas em identidades (IAM) e de políticas de recursos do AWS Glue.
**Contents**
+ [Exemplos das políticas baseadas em identidade do AWS Glue](security_iam_id-based-policy-examples.md)
+ [Práticas recomendadas de política](security_iam_id-based-policy-examples.md#security_iam_service-with-iam-policy-best-practices)
+ [As permissões em nível de recurso só se aplicam a objetos específicos do AWS Glue](security_iam_id-based-policy-examples.md#glue-identity-based-policy-limitations)
+ [Usar o console do AWS Glue](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-console)
+ [Permitir que os usuários visualizem suas próprias permissões](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-view-own-permissions)
+ [Conceder permissões somente de leitura para uma tabela](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-read-only-table-access)
+ [Filtrar tabelas pela permissão GetTables](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-filter-tables)
+ [Conceder total acesso a uma tabela e a todas as partições](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-full-access-tables-partitions)
+ [Controlar acesso por prefixo de nome e negação explícita](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-deny-by-name-prefix)
+ [Conceder acesso usando tags](security_iam_id-based-policy-examples.md#tags-control-access-example-triggers-allow)
+ [Negar acesso usando tags](security_iam_id-based-policy-examples.md#tags-control-access-example-triggers-deny)
+ [Usar tags com as operações de API de lista e lote](security_iam_id-based-policy-examples.md#tags-control-access-example-triggers-list-batch)
+ [Controlar as configurações usando chaves de condição ou chaves de contexto](security_iam_id-based-policy-examples.md#glue-identity-based-policy-condition-keys)
+ [Controlar políticas que controlam configurações usando chaves de condição](security_iam_id-based-policy-examples.md#glue-identity-based-policy-condition-key-vpc)
+ [Controlar políticas que controlam configurações usando chaves de contexto](security_iam_id-based-policy-examples.md#glue-identity-based-policy-context-key-glue)
+ [Negação da capacidade de criar sessões de pré-visualização de dados para uma identidade](security_iam_id-based-policy-examples.md#deny-data-preview-sessions-per-identity)
+ [Exemplos de política baseada em recursos para o AWS Glue](security_iam_resource-based-policy-examples.md)
+ [Considerações sobre o uso de políticas baseadas em recurso com o AWS Glue](security_iam_resource-based-policy-examples.md#security_iam_resource-based-policy-examples-considerations)
+ [Usar uma política de recurso para controlar o acesso na mesma conta](security_iam_resource-based-policy-examples.md#glue-policy-resource-policies-example-same-account)
# Exemplos das políticas baseadas em identidade do AWS Glue
Por padrão, os usuários e os perfis não têm permissão para criar ou modificar os recursos do AWS Glue. Para conceder permissão aos usuários para executar ações nos recursos que eles precisam, um administrador do IAM pode criar políticas do IAM.
Para saber como criar uma política baseada em identidade do IAM usando este exemplo de documento de política JSON, consulte [Criar políticas do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) no *Guia do usuário do IAM*.
Para obter detalhes sobre ações e tipos de recurso definidos pelo AWS Glue, incluindo o formato dos ARNs para cada tipo de recurso, consulte [Ações, recursos e chaves de condição do AWS Glue](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html) na *Referência de autorização do serviço*.
**nota**
Todos os exemplos fornecidos nesta seção usam a região `us-west-2`. Você pode substituí-la pela região da AWS que quiser usar.
**Topics**
+ [Práticas recomendadas de política](#security_iam_service-with-iam-policy-best-practices)
+ [As permissões em nível de recurso só se aplicam a objetos específicos do AWS Glue](#glue-identity-based-policy-limitations)
+ [Usar o console do AWS Glue](#security_iam_id-based-policy-examples-console)
+ [Permitir que os usuários visualizem suas próprias permissões](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Conceder permissões somente de leitura para uma tabela](#security_iam_id-based-policy-examples-read-only-table-access)
+ [Filtrar tabelas pela permissão GetTables](#security_iam_id-based-policy-examples-filter-tables)
+ [Conceder total acesso a uma tabela e a todas as partições](#security_iam_id-based-policy-examples-full-access-tables-partitions)
+ [Controlar acesso por prefixo de nome e negação explícita](#security_iam_id-based-policy-examples-deny-by-name-prefix)
+ [Conceder acesso usando tags](#tags-control-access-example-triggers-allow)
+ [Negar acesso usando tags](#tags-control-access-example-triggers-deny)
+ [Usar tags com as operações de API de lista e lote](#tags-control-access-example-triggers-list-batch)
+ [Controlar as configurações usando chaves de condição ou chaves de contexto](#glue-identity-based-policy-condition-keys)
+ [Negação da capacidade de criar sessões de pré-visualização de dados para uma identidade](#deny-data-preview-sessions-per-identity)
## Práticas recomendadas 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 gerenciadas pela AWS e avance para as permissões de privilégio mínimo**: para começar a conceder permissões a seus usuários e workloads, use as *políticas gerenciadas pela AWS*, que concedem permissões para muitos casos de uso comuns. Elas estão disponíveis em seus Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo cliente da AWS que são específicas para seus casos de uso. Para saber mais, consulte [Políticas gerenciadas pela AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [Políticas gerenciadas pela AWS para funções de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) no *Guia do usuário do IAM*.
+ **Aplique permissões de privilégio mínimo**: ao definir permissões com as políticas do IAM, conceda apenas as permissões necessárias para executar uma tarefa. Você faz isso definindo as ações que podem ser executadas em recursos específicos sob condições específicas, também conhecidas como *permissões de privilégio mínimo*. Para saber mais sobre como usar o IAM para aplicar permissões, consulte [Políticas e permissões no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*.
+ **Use condições nas políticas do IAM para restringir ainda mais o acesso**: é possível adicionar uma condição às políticas para limitar o acesso a ações e recursos. Por exemplo, é possível escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usando SSL. Também pode usar condições para conceder acesso a ações de serviço, se elas forem usadas por meio de um AWS service (Serviço da AWS) específico, como o CloudFormation. Para saber mais, consulte [Elementos da política JSON do IAM: condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) no *Guia do usuário do IAM*.
+ **Use o IAM Access Analyzer para validar suas políticas do IAM a fim de garantir permissões seguras e funcionais**: o IAM Access Analyzer valida as políticas novas e existentes para que elas sigam a linguagem de política do IAM (JSON) e as práticas recomendadas do IAM. O IAM Access Analyzer oferece mais de cem verificações de política e recomendações práticas para ajudar a criar políticas seguras e funcionais. Para saber mais, consulte [Validação de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) no *Guia do Usuário do IAM*.
+ **Exigir autenticação multifator (MFA)**: se houver um cenário que exija usuários do IAM ou um usuário raiz em sua Conta da AWS, ative a MFA para obter segurança adicional. Para exigir MFA quando as operações de API forem chamadas, adicione condições de MFA às suas políticas. Para saber mais, consulte [Configuração de acesso à API protegido por MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) no *Guia do Usuário do IAM*.
Para saber mais sobre as práticas recomendadas do IAM, consulte [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) no *Guia do usuário do IAM*.
## As permissões em nível de recurso só se aplicam a objetos específicos do AWS Glue
Só é possível definir um controle minucioso para objetos específicos no AWS Glue. Portanto, é necessário gravar a política do IAM do cliente para que as operações de API que permitem nomes de recurso da Amazon (ARNs) para a instrução `Resource` não sejam misturadas com operações de API que não permitem ARNs.
Por exemplo, a política do IAM a seguir permite operações de API para `GetClassifier` e `GetJobRun`. Ela define o `Resource` como `*`, pois o AWS Glue não permite ARNs para classificadores e execuções de tarefa. Como ARNs são permitidos para operações de API específicas, como `GetDatabase` e `GetTable`, os ARNs podem ser especificados na segunda metade da política.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetClassifier*",
"glue:GetJobRun*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"glue:Get*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/default",
"arn:aws:glue:us-east-1:111122223333:table/default/e*1*",
"arn:aws:glue:us-east-1:111122223333:connection/connection2"
]
}
]
}
```
------
Para obter uma lista de objetos do AWS Glue que permitem ARNs, consulte [Especificar ARNs de recursos do AWS Glue](glue-specifying-resource-arns.md).
## Usar o console do AWS Glue
Para acessar o console do AWS Glue, você deve ter um conjunto mínimo de permissões. Essas permissões devem autorizar você a listar e visualizar detalhes sobre os recursos do AWS Glue na sua 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.
Não é necessário conceder permissões mínimas do console para usuários que fazem chamadas somente à AWS CLI ou à API do AWS. Em vez disso, permita o acesso somente a ações que correspondam à operação de API que estiverem tentando executar.
Para garantir que os usuários e os perfis ainda possam usar o console do AWS Glue, anexe também a política `ConsoleAccess` ou `ReadOnly` do AWS Glue gerenciada pela AWS às entidades. Para saber mais, consulte [Adicionar permissões a um usuário](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) no *Guia do usuário do IAM*.
Para que um usuário trabalhe com o console do AWS Glue, ele deve ter um conjunto mínimo de permissões que liberem o trabalho com os recursos do AWS Glue na conta da AWS. Além dessas permissões do AWS Glue, o console exige permissões dos seguintes serviços:
+ Permissões do Amazon CloudWatch Logs para exibir logs.
+ AWS Identity and Access ManagementPermissões do (IAM) para listar e transmitir funções.
+ AWS CloudFormationPermissões do para trabalhar com pilhas.
+ Permissões do Amazon Elastic Compute Cloud (Amazon EC2) para listar VPCs, 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 (Amazon RDS) para listar instâncias.
Para obter mais informações sobre as permissões que os usuários necessitam para visualizar e trabalhar com o console do AWS Glue, consulte [Etapa 3: anexar uma política aos usuários ou grupos que acessam o AWS Glue](attach-policy-iam-user.md).
Se você criar uma política do IAM que seja mais restritiva que as permissões mínimas necessárias, o console não funcionará como pretendido para os usuários com essa política do IAM. Para garantir que esses usuários ainda possam usar o console do AWS Glue, anexe também a política gerenciada `AWSGlueConsoleFullAccess`, conforme descrito em [AWS Políticas gerenciadas pela (predefinidas) para o AWS Glue](security-iam-awsmanpol.md#access-policy-examples-aws-managed).
## Permitir que os usuários visualizem suas próprias permissões
Este exemplo mostra como criar uma política que permita que os usuários do IAM visualizem as políticas gerenciadas e em linha anexadas a sua identidade de usuário. Essa política inclui permissões para concluir essa ação no console ou de forma programática usando a AWS CLI ou a API da 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 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 como usar nomes de recurso da Amazon (ARNs), consulte [ARNs do Data Catalog](glue-specifying-resource-arns.md#data-catalog-resource-arns).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesActionOnBooks",
"Effect": "Allow",
"Action": [
"glue:GetTables",
"glue:GetTable"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/books"
]
}
]
}
```
------
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`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:CreateTable"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:table/db1/tbl1",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:catalog"
]
}
]
}
```
------
## Filtrar tabelas pela permissão GetTables
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).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesExample",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/store_sales",
"arn:aws:glue:us-east-1:111122223333:table/db1/stores"
]
}
]
}
```
------
Você pode simplificar a política anterior usando `store*` para corresponder a todos os nomes de tabelas que comecem com `store`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesExample2",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/store*"
]
}
]
}
```
------
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`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesReturnAll",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/*"
]
}
]
}
```
------
Se nenhum ARN de tabela for fornecido, uma chamada para `GetTables` será bem-sucedida, mas retornará uma lista vazia.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesEmptyResults",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1"
]
}
]
}
```
------
Se o ARN do banco de dados estiver ausente na política, haverá uma falha na chamada para `GetTables` com uma `AccessDeniedException`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesAccessDeny",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:table/db1/*"
]
}
]
}
```
------
## Conceder 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.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FullAccessOnTable",
"Effect": "Allow",
"Action": [
"glue:CreateTable",
"glue:GetTable",
"glue:GetTables",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:BatchDeleteTable",
"glue:GetTableVersion",
"glue:GetTableVersions",
"glue:DeleteTableVersion",
"glue:BatchDeleteTableVersion",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetPartition",
"glue:GetPartitions",
"glue:BatchGetPartition",
"glue:UpdatePartition",
"glue:DeletePartition",
"glue:BatchDeletePartition"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/books"
]
}
]
}
```
------
A política anterior pode ser simplificada na prática.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FullAccessOnTable",
"Effect": "Allow",
"Action": [
"glue:*Table*",
"glue:*Partition*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/books"
]
}
]
}
```
------
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 são organizados usando prefixos de nomes. 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 dados, tabelas, UDFs, e assim por diante, que têm o prefixo `dev-`. Mas você concede acesso somente leitura a tudo com o prefixo `prod-`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DevAndProdFullAccess",
"Effect": "Allow",
"Action": [
"glue:*Database*",
"glue:*Table*",
"glue:*Partition*",
"glue:*UserDefinedFunction*",
"glue:*Connection*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/dev-*",
"arn:aws:glue:us-east-1:111122223333:database/prod-*",
"arn:aws:glue:us-east-1:111122223333:table/dev-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/dev-*",
"arn:aws:glue:us-east-1:111122223333:table/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/dev-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/dev-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:connection/dev-*",
"arn:aws:glue:us-east-1:111122223333:connection/prod-*"
]
},
{
"Sid": "ProdWriteDeny",
"Effect": "Deny",
"Action": [
"glue:*Create*",
"glue:*Update*",
"glue:*Delete*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:database/prod-*",
"arn:aws:glue:us-east-1:111122223333:table/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:connection/prod-*"
]
}
]
}
```
------
A segunda instrução na política anterior usa explícita `deny`. 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 * * ? *)"
}
]
}
```
O administrador do AWS Glue anexou um valor de tag `Tom` (`aws:ResourceTag/Name": "Tom"`) ao gatilho `t2`. O administrador do AWS Glue também concedeu a Tom uma política do IAM com uma instrução de condição baseada na tag. Como resultado, Tom só pode usar uma operação do AWS Glue que atue sobre recursos com o valor de tag `Tom`.
------
#### [ JSON ]
****
```
{
"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 com êxito `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 não pode usar a operação de API `GetTriggers` plural para listar triggers porque essa operação não é compatível com filtragem por tags.
Para conceder acesso a `GetTriggers` para Tom, o administrador do AWS Glue cria uma política que divide as permissões em duas seções. Uma seção permite que Tom acesse todos os gatilhos com a operação da API `GetTriggers`. A segunda seção permite que Tom acesse as operações de API marcadas com o valor `Tom`. Com essa política, Tom tem permissão de acesso a `GetTriggers` e `GetTrigger` para o gatilho `t2`.
------
#### [ JSON ]
****
```
{
"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 operações de API no plural, como `GetTriggers`.
No exemplo de política a seguir, todas as operações de trabalho do AWS Glue 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`.
## Usar tags com as operações de API de lista e lote
Uma terceira abordagem para escrever uma política de recurso é permitir o acesso aos recursos usando uma operação da API `List` para listar os recursos para um valor de tag. Depois, use a operação da API `Batch` correspondente para permitir o acesso aos detalhes de recursos específicos. Com essa abordagem, o administrador não precisa conceder acesso às operações de API plurais `GetCrawlers`, `GetDevEndpoints`, `GetJobs` ou `GetTriggers`. Em vez disso, você pode permitir a possibilidade de listar os recursos com as seguintes operações de API:
+ `ListCrawlers`
+ `ListDevEndpoints`
+ `ListJobs`
+ `ListTriggers`
E você pode permitir a capacidade de obter detalhes sobre os recursos individuais com as seguintes operações de API:
+ `BatchGetCrawlers`
+ `BatchGetDevEndpoints`
+ `BatchGetJobs`
+ `BatchGetTriggers`
Como administrador, para usar essa abordagem, faça o seguinte:
1. Adicionar tags a seus crawlers, endpoints de desenvolvimento, trabalhos e gatilhos.
1. Negar o acesso de usuário a operações de API `Get`, como `GetCrawlers`, `GetDevEndponts`, `GetJobs` e `GetTriggers`.
1. Para permitir que os usuários descubram a quais recursos marcados eles têm acesso, conceda acesso de usuário a operações de API `List`, como `ListCrawlers`, `ListDevEndponts`, `ListJobs` e `ListTriggers`.
1. Negar o acesso de usuário a APIs de marcação do AWS Glue, como `TagResource` e `UntagResource`.
1. Conceder acesso de usuário aos detalhes de recursos com operações de API `BatchGet`, como `BatchGetCrawlers`, `BatchGetDevEndponts`, `BatchGetJobs` e `BatchGetTriggers`.
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ó deverá ser capaz de recuperar detalhes de triggers marcados com `Tom`, o administrador poderá adicionar tags aos triggers para `Tom`, negar o acesso à operação de API `GetTriggers` a todos os usuários e permitir o acesso de todos os usuários a `ListTriggers` e `BatchGetTriggers`.
Esta é a política de recurso que o administrador do AWS Glue concede a Tom. Na primeira seção da política, as operações de API do AWS Glue são negadas para `GetTriggers`. 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`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "glue:GetTriggers",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"glue:ListTriggers"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"glue:BatchGetTriggers"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Name": "Tom"
}
}
}
]
}
```
------
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](#glue-identity-based-policy-condition-key-vpc)
+ [Controlar políticas que controlam configurações usando chaves de contexto](#glue-identity-based-policy-context-key-glue)
### Controlar políticas que controlam configurações usando chaves de condição
O AWS Glue fornece três chaves de condição do IAM, `glue:VpcIds`, `glue:SubnetIds` e `glue:SecurityGroupIds`. Você pode usar chaves de condição nas políticas do IAM ao conceder permissões para criar e atualizar trabalhos. Você pode usar essa configuração para garantir que os trabalhos ou sessões não sejam criados (ou atualizados) para serem executados fora de um ambiente de VPC desejado. As informações de configuração da VPC não são uma entrada direta da solicitação `CreateJob`, mas são inferidas do campo "conexões" do trabalho que aponta para uma conexão do AWS Glue.
**Exemplo de uso**
Crie uma conexão de tipo de rede do AWS Glue denominada "traffic-monitored-connection" com o VpcId "vpc-id1234", SubnetIds e SecurityGroupIds desejados.
Especifique a condição das chaves de condição para as ações `CreateJob` e `UpdateJob` na política do IAM.
```
{
"Effect": "Allow",
"Action": [
"glue:CreateJob",
"glue:UpdateJob"
],
"Resource": [
"*"
],
"Condition": {
"ForAnyValue:StringLike": {
"glue:VpcIds": [
"vpc-id1234"
]
}
}
}
```
Você pode criar uma política do IAM semelhante para proibir a criação de um trabalho do AWS Glue sem especificar informações de conexão.
**Restringir sessões em VPCs**
Para forçar que as sessões criadas sejam executadas em uma VPC especificada, você restringe a permissão do perfil adicionando um efeito `Deny` na ação `glue:CreateSession` com a condição de que glue:vpc-id not equal to vpc-<123>. Por exemplo:
```
"Effect": "Deny",
"Action": [
"glue:CreateSession"
],
"Condition": {
"StringNotEquals" : {"glue:VpcIds" : ["vpc-123"]}
}
```
Você também pode forçar que as sessões criadas sejam executadas em uma VPC adicionando um efeito `Deny` na ação `glue:CreateSession` 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
O Glue da AWS fornece uma chave de contexto (`glue:CredentialIssuingService= glue.amazonaws.com`) para cada sessão de função que o AWS Glue disponibiliza para o endpoint do trabalho e do desenvolvedor. Isso permite que você implemente controles de segurança para as medidas tomadas pelo scripts do AWS Glue. O AWS Glue fornece outra chave de contexto (`glue:RoleAssumedBy=glue.amazonaws.com`) para cada sessão de perfil em que o AWS Glue faz uma chamada para outro serviço da AWS em nome do cliente (não por um endpoint de trabalho/desenvolvimento, mas diretamente pelo serviço AWS Glue).
**Exemplo de uso**
Especifique a permissão condicional na política do IAM e anexe-a ao perfil a ser usado por um trabalho do AWS Glue. Isso garante que determinadas ações sejam permitidas/negadas dependendo de a sessão de perfil ser ou não usada para um ambiente de runtime de trabalho do AWS Glue.
```
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-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
Essa seção contém um exemplo de política do IAM usado para negar a capacidade de criar sessões de pré-visualização de dados para uma identidade. 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*"
]
}
```
# Exemplos de política baseada em recursos para o AWS Glue
Esta seção contém exemplos de políticas baseadas em recursos, incluindo políticas que concedem acesso entre contas.
Os exemplos a seguir usam a AWS Command Line Interface (AWS CLI) para interagir com as operações de API do serviço AWS Glue. Você pode executar as mesmas operações no console do AWS Glue ou usar um dos SDKs da AWS.
**Importante**
Ao alterar uma política de recurso do AWS Glue, você pode acidentalmente revogar permissões para usuários do AWS Glue existentes em sua conta e provocar interrupções inesperadas. Antes de fazer as alterações, tente estes exemplos apenas em contas de desenvolvimento ou de teste e garanta que elas não interrompam nenhum fluxo de trabalho existente.
**Topics**
+ [Considerações sobre o uso de políticas baseadas em recurso com o AWS Glue](#security_iam_resource-based-policy-examples-considerations)
+ [Usar uma política de recurso para controlar o acesso na mesma conta](#glue-policy-resource-policies-example-same-account)
## Considerações sobre o uso de políticas baseadas em recurso com o AWS Glue
**nota**
As políticas do IAM e uma política de recursos do AWS Glue levam alguns segundos para serem propagadas. Depois de anexar uma nova política, você pode perceber que a política antiga ainda está em vigor até que a nova política tenha sido propagada pelo sistema.
Você usa um documento de política escrito em formato JSON para criar ou modificar uma política de recurso. A sintaxe da política é a mesma que a de uma política do IAM baseada em identidade (consulte [Referência de política JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)), com as seguintes exceções:
+ Um bloco `"Principal"` ou `"NotPrincipal"` é necessário para cada declaração da política.
+ O `"Principal"` ou o `"NotPrincipal"` devem identificar as entidades principais válidos existentes. Padrões de curinga (como `arn:aws:iam::account-id:user/*`) não são permitidos.
+ O bloco `"Resource"` da política exige que todos os ARNs de recursos correspondam à seguinte sintaxe de expressão regular (em que o primeiro `%s` é a *região* e o segundo `%s` é o *account-id*):
```
*arn:aws:glue:%s:%s:(\*|[a-zA-Z\*]+\/?.*)
```
Por exemplo, `arn:aws:glue:us-west-2:account-id:*` e `arn:aws:glue:us-west-2:account-id:database/default` são permitidos, mas `*` não é permitido.
+ Ao contrário das políticas baseadas em identidade, a política de recurso do AWS Glue deve conter apenas os nomes dos recursos da Amazon (ARN) que pertencem ao catálogo ao qual a política está anexada. Esses ARNs sempre começam com `arn:aws:glue:`.
+ Uma política não pode impedir que a identidade criada por ela crie ou modifique mais a política.
+ Um documento JSON de política de recurso não pode exceder 10 KB.
## Usar uma política de recurso para controlar o acesso na mesma conta
Neste exemplo, um usuário administrador na conta A cria uma política de recursos que concede à usuária do IAM `Alice` acesso total ao catálogo na conta A. Alice não tem nenhuma política do IAM anexada.
Para fazer isso, o usuário administrador executa o comando da AWS CLI a seguir.
```
# Run as admin of Account A
$ aws glue put-resource-policy --profile administrator-name --region us-west-2 --policy-in-json '{
"Version": "2012-10-17",
"Statement": [
{
"Principal": {
"AWS": [
"arn:aws:iam::account-A-id:user/Alice"
]
},
"Effect": "Allow",
"Action": [
"glue:*"
],
"Resource": [
"arn:aws:glue:us-west-2:account-A-id:*"
]
}
]
}'
```
Em vez de inserir o documento de política JSON como parte do comando da AWS CLI, você pode salvar um documento de política em um arquivo e fazer referência ao caminho do arquivo no comando da AWS CLI, com o prefixo `file://`. Este é um exemplo de como é possível fazer isso:
```
$ echo '{
"Version": "2012-10-17",
"Statement": [
{
"Principal": {
"AWS": [
"arn:aws:iam::account-A-id:user/Alice"
]
},
"Effect": "Allow",
"Action": [
"glue:*"
],
"Resource": [
"arn:aws:glue:us-west-2:account-A-id:*"
]
}
]
}' > /temp/policy.json
$ aws glue put-resource-policy --profile admin1 \
--region us-west-2 --policy-in-json file:///temp/policy.json
```
Depois que essa política de recurso tiver sido propagada, Alice poderá acessar todos os recursos do AWS Glue na Conta A, conforme a seguir.
```
# Run as user Alice
$ aws glue create-database --profile alice --region us-west-2 --database-input '{
"Name": "new_database",
"Description": "A new database created by Alice",
"LocationUri": "s3://amzn-s3-demo-bucket"
}'
$ aws glue get-table --profile alice --region us-west-2 --database-name "default" --table-name "tbl1"}
```
Em resposta à chamada `get-table` de Alice, o serviço AWS Glue retorna o seguinte:
```
{
"Table": {
"Name": "tbl1",
"PartitionKeys": [],
"StorageDescriptor": {
......
},
......
}
}
```