Gerenciamento de identidades e acesso no Amazon Elasticsearch Service - Amazon Elasticsearch Service

Se fornecermos uma tradução da versão em inglês do guia, a versão em inglês prevalecerá caso haja qualquer conflito entre as versões. A tradução é fornecida com o uso de tradução por máquina.

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.

Importante

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-user não poderá acessar dados de outros domínios.

  • Os caracteres finais /* no elemento Resource sã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-user pode 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 test-user pode realizar apenas uma operação: procura contra test-index. Todos os outros índices dentro do domínio estão inacessíveis e sem permissões para utilizar o es:ESHttpPut ou es:ESHttpPost acções, test-user não pode adicionar ou modificar documentos.

Em seguida, você pode optar por configurar uma função para usuários avançados. Esta política oferece acesso power-user-role 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ê poderá usar políticas baseadas em recursos no Amazon ES para oferecer acesso a índices e APIs do Elasticsearch aos usuários.

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 seguinte política concede acesso a ações que comecem com Describe e List. Esta combinação de ações fornece acesso apenas de leitura às configurações de domínio, mas não aos dados armazenados no domínio propriamente dito:

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

nota

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 e o Kibana ou acessar o domínio por meio de um servidor de proxy. Para saber mais, consulte Usar um proxy para acessar o Amazon ES do Kibana.

nota

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 as suas políticas especificam usuários ou funções do IAM, as solicitações para as APIs do Elasticsearch devem 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 um dos SDKs da AWS. Os SDKs simplificam muito o processo e podem economizar uma quantidade significativa de tempo em comparação com a criação e assinatura das 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 gerencia automaticamente a assinatura de solicitações:

    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 as APIs do Elasticsearch, você precisará 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. As APIs do Elasticsearch usam o formato a seguir:

    domain-id.region.es.amazonaws.com

    Por exemplo, a seguinte solicitação procura o índice movies para thor:

    GET https://my-domain.us-east-1.es.amazonaws.com/movies/_search?q=thor
nota

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

Negar Permitir
Denied in Identity-based Policy Negar Negar Negar
Neither Allowed nor Denied in Identity-based Policy Permitir Negar Negar

Referência de elementos de política

Amazon ES apoia a maioria dos elementos da política no Referência dos elementos da política de IE, com exceção de NotPrincipal. A tabela seguinte mostra os elementos mais comuns.

Elemento da política de JSON Resumo
Version

A versão atual do idioma da apólice é 2012-10-17. Todas as políticas de acesso devem especificar este valor.

Effect

Esse elemento especifica se a declaração permite ou nega o acesso às ações especificadas. Os valores válidos são Allow ou Deny.

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:

  • Contas AWS: "Principal":{"AWS": ["123456789012"]} ou "Principal":{"AWS": ["arn:aws:iam::123456789012:root"]}

  • Usuários do IAM: "Principal":{"AWS": ["arn:aws:iam::123456789012:user/test-user"]}

  • Funções do IAM: "Principal":{"AWS": ["arn:aws:iam::123456789012:role/test-role"]}

Especificar o curinga * permite o acesso anônimo ao domínio, o que não recomendamos, a menos que você adicione uma condição baseada em IP, use o suporte à VPC ou habilite o controle de acesso refinado.

Action

O Amazon ES usa as seguintes ações para os métodos HTTP:

  • es:ESHttpDelete

  • es:ESHttpGet

  • es:ESHttpHead

  • es:ESHttpPost

  • es:ESHttpPut

  • es:ESHttpPatch

O Amazon ES usa as seguintes ações para a API de configuração:

  • es:AddTags

  • es:CreateElasticsearchDomain

  • es:CreateElasticsearchServiceRole

  • es:DeleteElasticsearchDomain

  • es:DeleteElasticsearchServiceRole

  • es:DescribeElasticsearchDomain

  • es:DescribeElasticsearchDomainConfig

  • es:DescribeElasticsearchDomains

  • es:DescribeElasticsearchInstanceTypeLimits

  • es:DescribeReservedElasticsearchInstanceOfferings

  • es:DescribeReservedElasticsearchInstances

  • es:ESCrossClusterGet

  • es:GetCompatibleElasticsearchVersions

  • es:ListDomainNames

  • es:ListElasticsearchInstanceTypeDetails

  • es:ListElasticsearchInstanceTypes

  • es:ListElasticsearchVersions

  • es:ListTags

  • es:PurchaseReservedElasticsearchInstanceOffering

  • es:RemoveTags

  • es:UpdateElasticsearchDomainConfig

dica

Você pode usar caracteres curinga para especificar um subconjunto de ações, como "Action":"es:*" ou "Action":"es:Describe*".

Determinadas ações es: dão suporte a permissões no nível do recurso. Por exemplo, você pode conceder a um usuário permissões para excluir um determinado domínio sem conceder a esse usuário permissões para excluir qualquer domínio. Outras ações se aplicam apenas ao serviço em si. Por exemplo, es:ListDomainNames não faz sentido no contexto de um único domínio e, portanto, requer um curinga.

Importante

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 es: ações e as agrupa de acordo com sua aplicação, ou seja, se elas se aplicam aos sub-recursos do domínio (test-domain/*), à configuração do domínio (test-domain) ou apenas ao serviço (*):

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpDelete", "es:ESHttpGet", "es:ESHttpHead", "es:ESHttpPost", "es:ESHttpPut", "es:ESHttpPatch" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Allow", "Action": [ "es:CreateElasticsearchDomain", "es:DeleteElasticsearchDomain", "es:DescribeElasticsearchDomain", "es:DescribeElasticsearchDomainConfig", "es:DescribeElasticsearchDomains", "es:ESCrossClusterGet", "es:GetCompatibleElasticsearchVersions", "es:UpdateElasticsearchDomainConfig" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain" }, { "Effect": "Allow", "Action": [ "es:AddTags", "es:CreateElasticsearchServiceRole", "es:DeleteElasticsearchServiceRole", "es:DescribeElasticsearchInstanceTypeLimits", "es:DescribeReservedElasticsearchInstanceOfferings", "es:DescribeReservedElasticsearchInstances", "es:ESCrossClusterGet", "es:ListDomainNames", "es:ListElasticsearchInstanceTypeDetails", "es:ListElasticsearchInstanceTypes", "es:ListElasticsearchVersions", "es:ListTags", "es:PurchaseReservedElasticsearchInstanceOffering", "es:RemoveTags" ], "Resource": "*" } ] }
nota

Embora as permissões no nível de recurso para es:CreateElasticsearchDomain possam parecer não intuitivas — afinal de contas, por que conceder permissões a um usuário para criar um domínio que já existe?— o uso de um curinga permite aplicar um esquema de nomenclatura simples aos seus domínios, como "Resource": "arn:aws:es:us-west-1:987654321098:domain/my-team-name-*".

Naturalmente, nada impede que você inclua ações juntamente com elementos de recursos menos restritivos, como estes:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpGet", "es:DescribeElasticsearchDomain" ], "Resource": "*" } ] }

Para saber mais sobre o emparelhamento de ações e recursos, consulte o elemento Resource nesta tabela.

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 aws:SecureTransport, à qual o Amazon ES não oferece suporte.

Ao configurar uma política baseada em IP, você especifica os endereços IP ou bloco CIDR como uma condição, como esta:

"Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/32" ] } }
Resource

O Amazon ES usa elementos Resource de três maneiras básicas:

  • Para ações que se aplicam ao Amazon ES em si, como es:ListDomainNames, ou que permitem o acesso completo, use a seguinte sintaxe:

    "Resource": "*"
  • Para as ações que envolvem uma configuração de domínio, como es:DescribeElasticsearchDomain, você pode usar a seguinte sintaxe:

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name"
  • Para as ações que se aplicam a um sub-recurso de domínio, como es:ESHttpGet, você pode usar a seguinte sintaxe:

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/*"

    Você não precisa usar um curinga. O Amazon ES permite que você defina uma política de acesso diferente para cada índice ou API do Elasticsearch. Por exemplo, você pode limitar as permissões de um usuário para o índice test-index:

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index"

    Em vez de acesso total ao test-index, você pode preferir limitar a política somente à API de pesquisa:

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/_search"

    Você pode até mesmo controlar o acesso a documentos individuais:

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/test-type/1"

    Essencialmente, se o Elasticsearch expressar o sub-recurso como um URI, você poderá controlar o acesso a ele usando uma política de acesso. Para ter ainda mais controle sobre quais recursos um usuário pode acessar, consulte Controle de acesso minucioso no Amazon Elasticsearch Service.

Para obter detalhes sobre quais ações dão suporte a permissões no nível do recurso, consulte o elemento Action nesta tabela.

Opções avançadas e considerações sobre a API

Amazon ES tem várias opções avançadas, uma das quais tem implicações de controlo de acesso: rest.action.multi.allow_explicit_index. Na sua definição predefinida de verdadeiro, permite aos utilizadores contornar as permissões de subrecursos 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. Porque Amazon ES utiliza url para controlar o acesso a subrecursos de domínio, test-user pode, de facto, utilizar a API em massa para fazer alterações restricted-index. Mesmo que o utilizador não tenha POST permissões no índice, o seguinte pedido parabéns:

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 irão parar 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 o acesso a determinados usuários para uma ou mais dessas 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-user ainda pode fazer chamadas, como GET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_search e GET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search para acessar os documentos no restricted-index.

  • Como o elemento Resource faz referência ao restricted-index/*, o test-user nã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 especificar restricted-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.