Правильная политика доступа для Amazon Elastic Search Cluster

Недавно я начал использовать новую службу Amazon Elasticsearch Service, и мне кажется, что я не могу понять, какая политика доступа мне нужна, поэтому я могу получать доступ только к службам из моих инстансов EC2, которым назначена конкретная роль IAM.

Вот пример политики доступа, которую я назначил для домена 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]/*"
    }
  ]
}

Но, как я уже сказал, это не работает. Я вхожу в экземпляр EC2 (к которому my_es_roleпривязана роль) и пытаюсь выполнить простой вызов curl на конечной точке «https: //*.es.amazonaws.com», я получаю следующую ошибку:

{"Сообщение": "Пользователь: анонимный не авторизован для выполнения: es: ESHttpGet на ресурсе: arn: aws: es: us-east-1: [ACCOUNT_ID]: domain / [ES_DOMAIN] /"}

Кто-нибудь знает, что мне нужно изменить в политике доступа, чтобы это работало?

Вы можете заблокировать доступ только для IAM, но как вы будете просматривать Kibana в своем браузере? Вы можете настроить прокси-сервер ( см. Модуль Gist и / или NPM ) или включить доступ как по IAM, так и по IP для просмотра результатов.

Мне удалось получить доступ к IAM с ограничением по IP с помощью следующей политики доступа. Обратите внимание, что порядок важен: я не мог заставить его работать с оператором на основе IP до оператора 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"
          ]
        }
      }
    }
  ]
}

У моего экземпляра EC2 есть профиль экземпляра с arn:aws:iam::aws:policy/AmazonESFullAccess политикой. Logstash должен подписывать запросы с помощью плагина вывода logstash-output-amazon-es . Logstash, запущенный на моем экземпляре EC2, включает такой раздел вывода:

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

Я могу получить доступ к Kibana с двух IP-адресов в политике доступа (192.168.1.0 и 192.168.1.1).

Согласно документу AWS и как вы (и я) только что протестировали, вы не можете ограничить доступ к домену AWS ES для роли / учетной записи / пользователя / ... и просто cURL его!

Стандартные клиенты, такие как curl, не могут выполнять подпись запроса, которая требуется для политик доступа на основе удостоверений. Вы должны использовать политику доступа на основе IP-адреса, которая разрешает анонимный доступ для успешного выполнения инструкций для этого шага. ( http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg-search.html )

Итак, у вас есть два основных решения:

• измените свою политику доступа и ограничьте ее IP-адресами, я думаю, вы не можете использовать частный IP-адрес, потому что ваш кластер ES, похоже, не принадлежит вашему VPC (по умолчанию или нет). Пожалуйста, используйте публичный IP
• подпишите свой запрос: http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains.html#es-managedomains-signing-service-requests

Подпись вашего запроса, вероятно, является лучшим решением, если вы хотите сохранить свою политику доступа как есть (которая более гибкая, чем ограничение IP-адресом), но кажется немного более сложной. Я пока не пробовал и не могу найти никаких документов, которые могли бы помочь.

Немного опоздал на вечеринку, но я смог решить ту же проблему, добавив подпись к своим запросам.

Если вы используете Python (как и я), вы можете использовать следующую библиотеку, чтобы упростить реализацию: https://github.com/DavidMuller/aws-requests-auth

У меня это сработало отлично.

Вам просто нужно полное имя пользователя в эластичной политике поиска.

В этом случае вы можете получить свое полное имя пользователя из самого сообщения об ошибке. В моем случае: "arn: aws: sts :: [ACCOUNT_ID]: предположительная роль / [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]/*"
        }
      ]

    }

Вы можете использовать политику на основе ресурсов или политику на основе идентификации, а не политику на основе IP, которая похожа на жесткое кодирование IP-адреса.

Но вам нужно использовать подпись версии 4, чтобы подписать запрос

Для реализации Java см. Http://mytechbites.blogspot.in/2017/04/secure-amazon-elastic-search-service.html

Необходимо изменить роль ARN. это будет выглядеть как "arn: aws: iam :: [ACCOUNT_ID]: role / service-role / my_es_role"

Я также пытаюсь сделать это, и у меня это работает, используя Allow access to the domain from specific IP(s)параметр с эластичным IP-адресом моего экземпляра EC2 (также может работать с использованием частного IP-адреса экземпляра, но я не слишком уверен)