Właściwa polityka dostępu dla Amazon Elastic Search Cluster

Niedawno zacząłem korzystać z nowej usługi Amazon Elasticsearch i nie potrafię określić, jakiej polityki dostępu potrzebuję, aby mieć dostęp tylko do usług z moich instancji EC2, które mają przypisaną określoną rolę IAM.

Oto przykład polityki dostępu, którą obecnie przypisałem dla domeny 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]/*"
    }
  ]
}

Ale jak powiedziałem, to nie działa. Loguję się do instancji EC2 (która ma my_es_roleprzypisaną rolę) i próbuję uruchomić proste wywołanie curl w punkcie końcowym „https: //*.es.amazonaws.com”, pojawia się następujący błąd:

{"Message": "Użytkownik: anonymous nie ma uprawnień do wykonywania: es: ESHttpGet on resource: arn: aws: es: us-east-1: [ACCOUNT_ID]: domain / [ES_DOMAIN] /"}

Czy ktoś wie, co muszę zmienić w polityce dostępu, żeby to zadziałało?

Możesz zablokować dostęp tylko do IAM, ale jak będziesz wyświetlać Kibana w swojej przeglądarce? Możesz skonfigurować serwer proxy ( zobacz moduł Gist i / lub NPM ) lub włączyć dostęp oparty na IAM i IP w celu przeglądania wyników.

Udało mi się uzyskać dostęp do IAM z ograniczonym dostępem IP z następującą polityką dostępu. Zwróć uwagę, że kolejność jest ważna: nie mogłem sprawić, by działała z instrukcją opartą na adresie IP przed instrukcją 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"
          ]
        }
      }
    }
  ]
}

Moja instancja EC2 ma profil instancji z arn:aws:iam::aws:policy/AmazonESFullAccess polityką. Logstash powinien podpisywać żądania przy użyciu wtyczki wyjściowej logstash-output-amazon-es . Logstash działający na mojej instancji EC2 zawiera następującą sekcję wyjściową:

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

Mam dostęp do Kibany z dwóch adresów IP w polityce dostępu (192.168.1.0 i 192.168.1.1).

Zgodnie z dokumentacją AWS i jak właśnie testowaliśmy (i ja), nie możesz ograniczyć dostępu do domeny AWS ES do roli / konta / użytkownika / ... i po prostu zakreślić ją!

Klienci standardowi, tacy jak curl, nie mogą wykonywać podpisywania żądań, które jest wymagane w przypadku zasad dostępu opartych na tożsamości. Aby pomyślnie wykonać instrukcje dla tego kroku, należy użyć zasad dostępu opartych na adresach IP, które umożliwiają dostęp anonimowy. ( http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg-search.html )

Masz więc zasadniczo dwa rozwiązania:

• zmień swoją politykę dostępu i ogranicz ją do adresów IP, myślę, że nie możesz używać prywatnego adresu IP, ponieważ twój klaster ES nie wydaje się należeć do twojego VPC (domyślnie lub nie). Użyj publicznego adresu IP
• podpisz swoje żądanie: http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains.html#es-managedomains-signing-service-requests

Podpisanie żądania jest prawdopodobnie najlepszym rozwiązaniem, jeśli chcesz zachować swoją politykę dostępu w obecnym kształcie (która jest bardziej elastyczna niż ograniczenie do adresu IP), ale wydaje się być nieco bardziej złożona. Nie próbowałem dotąd i nie mogę znaleźć żadnego doktora, który mógłby pomóc.

Trochę spóźniłem się na przyjęcie, ale udało mi się poradzić sobie z tym samym problemem, dodając podpis do moich wniosków.

Jeśli używasz Pythona (tak jak ja), możesz użyć następującej biblioteki, aby ułatwić jej wdrożenie: https://github.com/DavidMuller/aws-requests-auth

U mnie zadziałało idealnie.

Wystarczy podać pełną nazwę użytkownika w zasadach elastycznego wyszukiwania.

W takim przypadku pełną nazwę użytkownika można uzyskać na podstawie samego komunikatu o błędzie. W moim przypadku: „arn: aws: sts :: [ACCOUNT_ID]: przejęta-rola / [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]/*"
        }
      ]

    }

Możesz użyć polityki opartej na zasobach lub polityki opartej na tożsamości zamiast polityki opartej na IP, która jest jak sztywne kodowanie adresu IP.

Ale do podpisania wniosku musisz użyć wersji Signature 4

W przypadku implementacji języka Java odwiedź http://mytechbites.blogspot.in/2017/04/secure-amazon-elastic-search-service.html

Rola ARN musi zostać zmieniona. będzie wyglądać następująco: „arn: aws: iam :: [ACCOUNT_ID]: role / service-role / my_es_role”

Próbuję to również zrobić, ale działało, używając Allow access to the domain from specific IP(s)opcji z elastycznym adresem IP mojej instancji EC2 (może również działać przy użyciu prywatnego adresu IP instancji, ale nie jestem zbyt pewien)