400 неверных запросов при попытке подключения к AWS Нептун с включенным IAM - PullRequest
Новая
       6

400 неверных запросов при попытке подключения к AWS Нептун с включенным IAM

1 голос
/ 13 марта 2020

Мне не удается подключиться к экземпляру Нептуна, для которого включен IAM. Я следовал документации AWS (исправил несколько моих глупых ошибок в пути), но безуспешно.

Когда я подключаюсь через свое приложение Java с помощью SigV4Signer и когда я использую консоль gremlin, Я получаю 400 ошибочных запросов веб-сокета. 

o.a.t.g.d.Handler$GremlinResponseHandler : Could not process the response

io.netty.handler.codec.http.websocketx.WebSocketHandshakeException: Invalid handshake response getStatus: 400 Bad Request
    at io.netty.handler.codec.http.websocketx.WebSocketClientHandshaker13.verify(WebSocketClientHandshaker13.java:267)
    at io.netty.handler.codec.http.websocketx.WebSocketClientHandshaker.finishHandshake(WebSocketClientHandshaker.java:302)
    at org.apache.tinkerpop.gremlin.driver.handler.WebSocketClientHandler.channelRead0(WebSocketClientHandler.java:69)

Когда я запускаю com.amazon.neptune.gremlin.driver.example.NeptuneGremlinSigV4Example (с моей машины через переадресацию портов И с точки доступа EC2), я получаю:

java.util.concurrent.TimeoutException: Timed out while waiting for an available host - check the client configuration and connectivity to the server if this message persists

Я могу подключиться к моему экземпляру Нептуна, используя устаревший устаревший механизм сертификатов. Я использую экземпляр Jumphost ec2 и переадресацию портов.

Я считаю, что аспект SigV4 работает так же, как в журналах аудита Нептуна. Я вижу попытки соединения с aws_access_key:

1584098990319, <jumphost_ip>:47390, <db_instance_ip>:8182, HTTP_GET, [unknown], [unknown], "HttpObjectAggregator$AggregatedFullHttpRequest(decodeResult: success, version: HTTP/1.1, content: CompositeByteBuf(ridx: 0, widx: 0, cap: 0, components=0)) GET /gremlin HTTP/1.1 upgrade: websocket connection: upgrade sec-websocket-key: g44zxck9hTI9cZrq05V19Q== sec-websocket-origin: http://localhost:8182 sec-websocket-version: 13 Host: localhost:8182 X-Amz-Date: 20200313T112950Z Authorization: AWS4-HMAC-SHA256 Credential=<my_access_key>/20200313/eu-west-2/neptune-db/aws4_request, SignedHeaders=host;sec-websocket-key;sec-websocket-origin;sec-websocket-version;upgrade;x-amz-date, Signature=<the_signature> content-length: 0", /gremlin

Но когда я смотрю

Это политика, которую я создал: 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "neptune-db:*"
            ],
            "Resource": [
                "arn:aws:neptune-db:eu-west-2:<my_aws_account>:*/*"
            ]
        }
    ]
}

Я ранее пробовал использовать политику, которая ссылается на идентификатор ресурса моего кластера. Я создал нового пользователя API с этой политикой в ​​качестве единственного разрешения. (Я пробовал это дважды).

IAM показывает, что созданный мной пользователь-граф не вошел в систему (дух).

Кажется, что проблема связана с набором IAM где-то вдоль линии. Можно ли из AWS получить больше информации о причине неудачной попытки подключения?

Я использую самый последний выпуск Neptune, а также драйвер и консоль Gremlin 3.4.3. Я использую Java 8 при запуске NeptuneGremlinSigV4Example и собираю библиотеки для развертывания на консоли.

спасибо

1 Ответ

3 голосов
/ 13 марта 2020

Из выходных данных журнала аудита видно, что создаваемая подпись SigV4 использует localhost в качестве заголовка Host. Скорее всего, это связано с тем, что вы используете прокси для подключения к Neptune. По умолчанию NeptuneGremlinSigV4Example предполагает, что вы подключаетесь непосредственно к конечной точке Neptune, и повторно использует конечную точку в качестве заголовка Host при создании подписи.

Чтобы обойти это, вы можете использовать следующий пример кода, который переопределяет этот процесс и позволяет использовать прокси-сервер и по-прежнему правильно подписывать запрос.

https://github.com/aws-samples/amazon-neptune-samples/tree/master/gremlin/gremlin-java-client-demo

Мне удалось заставить это работать, используя следующее.

  • Создайте туннель SSL от вашей локальной рабочей станции до вашей точки перехода EC2: 
ssh -i <key-pem-file> -L 8182:<neptune-endpoint>:8182 ec2-user@<ec2-jumphost-hostname>
  • Задайте следующие переменные среды: 
export AWS_ACCESS_KEY_ID=<access_key>
export AWS_SECRET_ACCESS_KEY=<secret_key>
export SERVICE_REGION=<region_id>  (i.e. us-west-2)
  • После запуска туннеля и установки переменных среды используйте следующий формат с Gremlin-Java-Client-Demo: 
java -jar target/gremlin-java-client-demo.jar --nlb-endpoint localhost --lb-port 8182 --neptune-endpoint <neptune-endpoint> --port 8182 --enable-ssl --enable-iam-auth
...