As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Gerenciamento de identidades e acesso no Amazon Elasticsearch Service
O Amazon Elasticsearch Service oferece várias opções para controlar o acesso aos seus domínios. Esta seção aborda os diversos tipos de política, como eles interagem entre si e como você pode criar suas próprias políticas personalizadas.
O suporte a VPC apresenta algumas considerações adicionais sobre o controle de acesso do Amazon ES. Para obter mais informações, consulte Sobre políticas de acesso em domínios da VPC.
Tipos de políticas
O Amazon ES oferece suporte a três tipos de políticas de acesso:
Políticas baseadas em recursos
Ao criar um domínio, é adicionada uma política baseada em recurso, às vezes chamada de política de acesso ao domínio. Essas políticas especificam que ações uma entidade principal pode executar nos sub-recursos do domínio. Os sub-recursos incluem índices do Elasticsearch e APIs.
O elemento Principal especifica as contas, os usuários ou as funções com acesso permitido. O elemento
Resource especifica quais sub-recursos essas entidades principais podem acessar. A política
baseada em recurso a seguir concede acesso total ao test-user (es:*) para o test-domain:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }
Duas considerações importantes se aplicam a essa política:
-
Esses privilégios se aplicam apenas a esse domínio. A menos que você crie políticas adicionais, o
test-usernão poderá acessar dados de outros domínios. -
Os caracteres finais
/*no elementoResourcesão significativos. As políticas baseadas em recurso só se aplicam aos sub-recursos do domínio, não ao próprio domínio.Por exemplo, o
test-userpode fazer solicitações em relação a um índice (GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index), mas não pode atualizar a configuração do domínio (POST https://es.us-west-1.amazonaws.com/2015-01-01/es/domain/test-domain/config). Observe a diferença entre os dois endpoints. O acesso à API de configuração requer uma política baseada em identidade.
Para restringir ainda mais o test-user, você pode aplicar a seguinte política:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/_search" } ] }
Agora o test-user pode executar apenas uma operação: pesquisar no test-index. Todos os outros índices no domínio são inacessíveis e, sem permissões para usar
as ações es:ESHttpPut ou es:ESHttpPost, o test-user não pode adicionar nem modificar documentos.
Em seguida, você pode optar por configurar uma função para usuários avançados. Essa
política concede ao power-user-role acesso aos métodos HTTP GET e PUT para todos os URIs no índice:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:role/power-user-role" ] }, "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*" } ] }
Para obter informações sobre todas as ações disponíveis, consulte Referência de elementos de política.
Políticas baseadas em identidade
Ao contrário do que ocorre com as políticas baseadas em recurso, que são associadas a domínios no Amazon ES, as políticas baseadas em identidade são associadas a usuários ou funções usando o serviço AWS Identity and Access Management (IAM). Assim como nas políticas baseadas em recursos, as políticas baseadas em identidade especificam quem pode acessar um serviço, quais ações podem ser executadas e, se aplicável, em quais recursos essas ações podem ser executadas.
As políticas baseadas em identidade tendem a ser mais genéricas, embora não exista essa exigência. Elas geralmente controlam somente as ações de API de configuração que um usuário pode realizar. Depois de estabelecer essas políticas, você pode usar políticas baseadas em recursos no Amazon ES para oferecer aos usuários acesso a índices e Elasticsearch do APIs.
Como as políticas baseadas em identidade são anexadas a usuários ou funções (principais),
o JSON não especifica um principal. A política a seguir concede acesso a ações que
começam com Describe e List. Essa combinação de ações fornece acesso somente leitura a configurações de domínio,
mas não aos dados armazenados no próprio domínio:
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:Describe*", "es:List*" ], "Effect": "Allow", "Resource": "*" } ] }
Um administrador pode ter acesso total ao Amazon ES e a todos os dados armazenados em todos os domínios:
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] }
Para obter mais informações sobre as diferenças entre as políticas baseadas em recursos e as baseadas em identidade, consulte Políticas do IAM no Guia do usuário do IAM.
Os usuários com a política gerenciada pela AWS AmazonESReadOnlyAccess não podem ver o status de integridade do cluster no console. Para permitir que eles
vejam o status de integridade do cluster, adicione a ação "es:ESHttpGet" a uma política de acesso e anexe-a às respectivas contas ou funções.
Políticas baseadas em IP
As políticas baseadas em IP restringem o acesso a um domínio para um ou mais endereços IP ou blocos CIDR. Tecnicamente, as políticas baseadas em IP não são um tipo de política diferente. Na verdade, elas são apenas políticas baseadas em recursos que especificam uma entidade principal anônima e incluem um elemento Condition especial.
O apelo principal das políticas baseadas em IP é que elas permitem solicitações não
assinadas a um domínio do Amazon ES, o que permite usar clientes como o curl
Se você ativou o acesso à VPC para seu domínio, não poderá configurar uma política baseada em IP. Em vez disso, você poderá usar grupos de segurança para controlar quais endereços IP poderão acessar o domínio. Para obter mais informações, consulte Sobre políticas de acesso em domínios da VPC.
A política a seguir concede a todas as solicitações HTTP que se originam no intervalo
de IP especificado acesso ao test-domain:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }
Se o seu domínio tiver um endpoint público e não usar controle de acesso minucioso, recomendamos combinar principais do IAM e endereços IP. Esta política concederá
acesso HTTP ao test-user somente se a solicitação se originar do intervalo de IP especificado:
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::987654321098:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }] }
Criar e assinar as solicitações Amazon ES
Mesmo que você configure uma política de acesso baseada em recursos completamente aberta, todas as solicitações para a API de configuração do Amazon ES devem ser assinadas. Se suas políticas especificarem usuários ou funções do IAM, as solicitações para o Elasticsearch APIs também deverão ser assinadas usando o AWS Signature versão 4. O método de assinatura é diferente dependendo da API:
-
Para fazer chamadas para a API de configuração do Amazon ES, recomendamos que você use uma das AWS SDKs
. O SDKs simplifica muito o processo e pode economizar uma quantidade significativa de tempo em comparação com a criação e assinatura de suas próprias solicitações. Os endpoints da API de configuração usam o formato a seguir: es.region.amazonaws.com/2015-01-01/Por exemplo, a seguinte solicitação faz uma alteração de configuração no domínio
movies, mas é necessário que você a assine (não recomendado):POST https://es.us-east-1.amazonaws.com/2015-01-01/es/domain/movies/config { "ElasticsearchClusterConfig": { "InstanceType": "c5.xlarge.elasticsearch" } }Se você usar um dos SDKs, como Boto 3
, o SDK lidará automaticamente com a assinatura da solicitação: import boto3 client = boto3.client('es') response = client.update_elasticsearch_domain_config( DomainName='movies', ElasticsearchClusterConfig={ 'InstanceType': 'c5.xlarge.elasticsearch' } )Para obter um exemplo de código Java, consulte Usar os SDKs da AWS com o Amazon Elasticsearch Service.
-
Para fazer chamadas para o Elasticsearch APIs, você deve assinar suas próprias solicitações. Para obter um exemplo de código em uma variedade de linguagens, consulte Assinar solicitações de HTTP para o Amazon Elasticsearch Service. O Elasticsearch APIs usa o seguinte formato:
domain-id.region.es.amazonaws.comPor exemplo, a seguinte solicitação procura o índice
moviespara thor:GET https://my-domain.us-east-1.es.amazonaws.com/movies/_search?q=thor
O serviço ignora parâmetros passados em URLs para solicitações HTTP POST assinadas com o Signature versão 4.
Quando há colisão de políticas
Quando as políticas discordam entre si ou não fazem nenhuma referência explícita a um usuário, surgem complexidades. Como funciona o IAM no Guia do usuário do IAM fornece um breve resumo da lógica de avaliação de políticas:
-
Por padrão, todas as solicitações são negadas.
-
Uma permissão explícita substitui esse padrão.
-
Uma negação explícita substitui todas as permissões.
Por exemplo, se uma política baseada em recursos concede acesso a um domínio, mas uma política baseada em identidade nega o acesso, esse acesso é negado. Se uma política baseada em identidade concede acesso e uma política baseada em recursos não especifica se você deve ou não ter acesso, esse acesso é concedido. Consulte a tabela a seguir com o cruzamento de políticas para obter um resumo completo dos resultados.
| Permitido na política baseada em recursos | Negado na política baseada em recursos | Nem permitido nem negado na política baseada em recursos | |
|---|---|---|---|
| Allowed in Identity-based Policy |
Permitir |
Deny | Permitir |
| Denied in Identity-based Policy | Deny | Deny | Deny |
| Neither Allowed nor Denied in Identity-based Policy | Permitir | Deny | Deny |
Referência de elementos de política
O Amazon ES oferece suporte à maioria dos elementos de política na Referência de elementos de política do IAMNotPrincipal, com exceção de . A tabela a seguir mostra os elementos mais comuns.
| Elemento da política de JSON | Resumo |
|---|---|
Version |
A versão atual da linguagem de política é |
Effect |
Esse elemento especifica se a declaração permite ou nega o acesso às ações especificadas.
Os valores válidos são |
Principal |
Esse elemento especifica a conta da AWS, ou usuário ou função do IAM, que tem ou não permissão para acessar um recurso e pode apresentar várias formas:
Especificar o curinga |
Action
|
O Amazon ES usa as seguintes ações para os métodos HTTP:
O Amazon ES usa as seguintes ações para a API de configuração:
Você pode usar caracteres curinga para especificar um subconjunto de ações, como Determinadas ações Políticas baseadas em recursos são diferentes das permissões no nível do recurso. As políticas baseadas em recursos são políticas JSON completas anexadas aos domínios. As permissões no nível do recurso tornam possível a restrição de ações em domínios específicos ou sub-recursos. Na prática, você pode pensar na permissão no nível do recurso como uma seção opcional de um recurso ou uma política baseada em identidade. A seguinte política baseada em identidade lista todas as
Embora as permissões no nível de recurso para Naturalmente, nada impede que você inclua ações juntamente com elementos de recursos menos restritivos, como estes:
Para saber mais sobre o emparelhamento de ações e recursos, consulte o elemento |
Condition |
O Amazon ES oferece suporte a maioria das condições descritas em Chaves de condição globais disponíveis no Guia do usuário do IAM. Uma exceção notável é a chave Ao configurar uma política baseada em IP, você especifica os endereços IP ou bloco CIDR como uma condição, como esta: |
Resource |
O Amazon ES usa elementos
Para obter detalhes sobre quais ações dão suporte a permissões no nível do recurso,
consulte o elemento |
Opções avançadas e considerações sobre a API
O Amazon ES tem várias opções avançadas, uma das quais tem implicações para o controle
de acesso: prest.action.multi.allow_explicit_index. Ela permite que os usuários ignorem as permissões de sub-recursos na configuração
padrão de true (verdadeiro) em determinadas circunstâncias.
Por exemplo, considere a seguinte política baseada em recurso:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Resource": [ "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*", "arn:aws:es:us-west-1:987654321098:domain/test-domain/_bulk" ] }, { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
Essa política concede ao test-user acesso total ao test-index e à API em massa do Elasticsearch. Ela também permite solicitações GET ao restricted-index.
A seguinte solicitação de indexação, como você pode esperar, falha devido a um erro de permissão:
PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1 { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }
Ao contrário da API de índice, a API em massa permite criar, atualizar e excluir vários
documentos em uma única chamada. Contudo, normalmente você especifica essas operações
no corpo da solicitação, em vez de na URL da solicitação. Como o Amazon ES usa o URLs
para controlar o acesso aos sub-recursos do domínio, o test-user pode, na verdade, usar a API em massa para fazer alterações no restricted-index. Embora o usuário não tenha permissões POST no índice, a seguinte solicitação é bem-sucedida:
POST https://search-test-domain.us-west-1.es.amazonaws.com/_bulk { "index" : { "_index": "restricted-index", "_type" : "movie", "_id" : "1" } } { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }
Nesta situação, a política de acesso não consegue cumprir o que pretendia. Para evitar
que os usuários ignorem esses tipos de restrições, você pode alterar o rest.action.multi.allow_explicit_index para o valor falso. Se esse valor for falso, todas as chamadas para as APIs em massa,
mget e msearch, que especificam nomes de índice no corpo da solicitação pararão de
funcionar. Em outras palavras, as chamadas para _bulk não funcionam mais, mas as chamadas para o test-index/_bulk funcionam. Este segundo endpoint contém um nome de índice, portanto, você não precisa
especificar um no corpo da solicitação.
O Kibana depende muito do mget e do msearch e, portanto, provavelmente não funcionará corretamente
após essa alteração. Para correção parcial, você pode deixar o rest.action.multi.allow_explicit_index como verdadeiro e negar acesso a determinados usuários a um ou mais desses APIs.
Para obter informações sobre como alterar essa configuração, consulte Opções avançadas.
Da mesma forma, a seguinte política baseada em recursos contém dois problemas sutis:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHTTP*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
-
Apesar da negação explícita, o
test-userainda pode fazer chamadas, comoGET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_searcheGET https://search-test-domain.us-west-1.es.amazonaws.com/*/_searchpara acessar os documentos norestricted-index. -
Como o elemento
Resourcefaz referência aorestricted-index/*, otest-usernão tem permissões para acessar diretamente os documentos do índice. O usuário, no entanto, tem permissões para excluir todo o índice. Para evitar o acesso e a exclusão, a política deve especificarrestricted-index*.
Em vez de misturar permissões amplas e negações focadas, a abordagem mais segura é seguir o princípio do privilégio mínimo e conceder apenas as permissões necessárias para executar uma tarefa. Para obter mais informações sobre como controlar o acesso a índices ou operações individuais do Elasticsearch, consulte Controle de acesso minucioso no Amazon Elasticsearch Service.
Configuração de políticas de acesso
-
Para obter instruções sobre a criação ou modificação de políticas baseadas em recursos e políticas baseadas em IP no Amazon ES, consulte Configuração de políticas de acesso.
-
Para obter instruções sobre como criar ou modificar políticas baseadas em identidade no IAM, consulte Como criar políticas do IAM no Guia do usuário do IAM.
Exemplos adicionais de políticas
Embora este capítulo inclua muitas amostras de políticas, o controle de acesso da AWS é um tema complexo que pode ser entendido melhor por meio de exemplos. Para obter mais informações, consulte Exemplos de políticas no Guia do usuário do IAM.
