Política de acesso adequada para Amazon Elastic Search Cluster


99

Recentemente, comecei a usar o novo Amazon Elasticsearch Service e não consigo descobrir a política de acesso de que preciso para poder acessar apenas os serviços de minhas instâncias EC2 que têm uma função IAM específica atribuída a elas.

Aqui está um exemplo da política de acesso que atualmente atribuí para o domínio ES:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::[ACCOUNT_ID]:role/my_es_role",
        ]
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-east-1:[ACCOUNT_ID]:domain/[ES_DOMAIN]/*"
    }
  ]
}

Mas, como eu disse, isso não funciona. Eu entro na instância EC2 (que tem a my_es_rolefunção anexada a ela) e tento executar uma chamada curl simples no ponto de extremidade "https: //*.es.amazonaws.com", recebo o seguinte erro:

{"Message": "Usuário: anonymous não está autorizado a executar: es: ESHttpGet no recurso: arn: aws: es: us-east-1: [ACCOUNT_ID]: domain / [ES_DOMAIN] /“}

Alguém sabe o que tenho que mudar na política de acesso para que funcione?


14
Cuidado, as alterações da política de acesso do ElasticSearch demoram muito para serem aplicadas, ao contrário de outras alterações do IAM que são quase instantâneas. É fácil apenas clicar em "aplicar" e alternar a guia sem perceber "Processando ..."
Cyril Duchon-Doris

Respostas:


63

Você pode bloquear o acesso apenas ao IAM, mas como verá o Kibana em seu navegador? Você pode configurar um proxy ( consulte o módulo Gist e / ou NPM ) ou habilitar o IAM e o acesso baseado em IP para visualizar os resultados.

Consegui obter acesso restrito por IP de acesso IAM com a seguinte Política de Acesso. Observe que a ordem é importante: não consegui fazê-lo funcionar com a instrução baseada em IP antes da instrução IAM.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::xxxxxxxxxxxx:root"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-west-2:xxxxxxxxxxxx:domain/my-elasticsearch-domain/*"
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-west-2:xxxxxxxxxxxx:domain/my-elasticsearch-domain/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.168.1.0",
            "192.168.1.1"
          ]
        }
      }
    }
  ]
}

Minha instância EC2 tem um perfil de instância com a arn:aws:iam::aws:policy/AmazonESFullAccess política. Logstash deve assinar solicitações usando o plugin de saída logstash-output-amazon-es . O Logstash em execução na minha instância EC2 inclui uma seção de saída como esta:

output {
    amazon_es {
        hosts => ["ELASTICSEARCH_HOST"]
        region => "AWS_REGION"
    }
    # If you need to do some testing & debugging, uncomment this line:
    # stdout { codec => rubydebug }
}

Posso acessar o Kibana a partir dos dois IPs da política de acesso (192.168.1.0 e 192.168.1.1).


Olá, você só precisa usar o plug-in se estiver usando uma política baseada em IAM. Você pode usar o plug-in elasticsearch padrão no Logstash se sua política de acesso for baseada em endereços IP. Você também não precisa de um perfil de instância nesse caso. Além disso, o serviço ES não está disponível em VPCs. Você deve usar endereços IP públicos para se conectar. Não tenho certeza se suas referências a endereços 192.168 são substituições de outra coisa, mas podem enganar.
Garreth McDaid

Os aws:SourceIp's no meu exemplo destinam-se a ser o IP da sua estação de trabalho pessoal para que você possa usar o Kibana. O acesso restrito ao IAM permite que uma ou mais instâncias do EC2 gravem no Elasticsearch sem se preocupar com quais IPs pertencem a uma determinada instância ou bloco CIDR.
Pete

1
É importante notar que limitar ao intervalo CIDR de IP privado do seu VPC parece não funcionar. ES não opera dentro do VPC ou algo assim.
sventechie

Obrigado por fornecer um exemplo de política em sua resposta; Eu não consegui fazer Kibana passar pelo temido erro "Usuário: anônimo" até que mudei aws:SourceIpde um valor escalar para um array, como no exemplo que você deu. (Sou a notação CIDR, se isso ajudar mais alguém.) Todo o processo de definição de políticas para AWS ES seria menos frustrante se cada mudança de política não colocasse o cluster no misterioso estado de "processamento" por 20 minutos, como a apólice está cuidadosamente inscrita em tábuas de pedra, ou o que quer que estejam fazendo.
Robert Calhoun

38

De acordo com o documento da AWS e como você (e eu) acabamos de testar, você não pode restringir o acesso a um domínio AWS ES a uma função / conta / usuário / ... e simplesmente CURL-lo!

Os clientes padrão, como curl, não podem executar a assinatura de solicitação exigida pelas políticas de acesso baseadas em identidade. Você deve usar uma política de acesso baseada em endereço IP que permita o acesso anônimo para executar com êxito as instruções desta etapa. ( http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg-search.html )

Portanto, você tem basicamente duas soluções:

Assinar sua solicitação é provavelmente a melhor solução se você deseja manter sua política de acesso como está (que é mais flexível do que restringir a um IP), mas parece ser um pouco mais complexo. Ainda não tentei e não consigo encontrar nenhum médico para ajudar.


3
Usei o endereço IP público do meu laptop e tentei acessar o endpoint com curl / navegador, mas ainda estou recebendo o erro Usuário: anônimo.
Anant Gupta

7
estou lidando com o mesmo problema. e percebi que o processamento das alterações por aws elasticsearch leva muito tempo.
nemo

Defina uma política de acesso com duas instruções: uma para acesso IAM para gravar logs, a outra com acesso restrito por IP para visualizar KIbana. Veja minha resposta para detalhes
Pete

2
Eu me perguntei se "loooong" significa minutos, horas ou dias. Parece que são 10-15 minutos. Você pode ver isso ao verificar o status do seu ES (verde 'ativo' se a atualização estiver concluída, senão, algo como uma laranja 'preparando'.
Balmipour

Tive o mesmo problema e depois de pesquisar encontrei esta biblioteca útil .
gmajivu

6

Um pouco tarde para a festa, mas fui capaz de lidar exatamente com o mesmo problema adicionando assinatura às minhas solicitações.

Se você usa Python (como eu), pode usar a seguinte biblioteca para torná-la particularmente fácil de implementar: https://github.com/DavidMuller/aws-requests-auth

Funcionou perfeitamente para mim.


1

Você só precisa inserir o nome de usuário completo na política de pesquisa elástica.

Nesse caso, você pode obter seu nome de usuário completo na própria mensagem de erro. No meu caso: "arn: aws: sts :: [ACCOUNT_ID]: papel assumido / [LAMBDA_POLICY_NAME] / [LAMBDA_NAME]"

    {
        "Version": "2012-10-17",
        "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "AWS": [
              "arn:aws:sts::xxxxxxxxxxxx:assumed-role/[lambda-role]/[full-lambda-name]"
            ]
          },
          "Action": "es:*",
          "Resource": "arn:aws:es:[region]:xxxxxxxxxxxxx:domain/[elasticsearch-domain-name]/*"
        }
      ]

    }


0

A função ARN precisa ser alterada. será semelhante a "arn: aws: iam :: [ACCOUNT_ID]: role / service-role / my_es_role"


-2

Também estou tentando fazer isso e consegui fazer funcionar usando a Allow access to the domain from specific IP(s)opção com o Elastic IP da minha instância EC2 (também poderia funcionar usando o IP privado da instância, mas não tenho certeza)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.