Neptune Local Development Access Methods
Question for the Neptune folks - I'm trying to cobble together ergonomic local access to our development cluster.
Here's what I've got that works:
- SSM session running via an EC2 bastion host, which makes the targeted cluster (using
AWS-StartPortForwardingSessionToRemoteHost
) available at localhost:8182
- A mapping in /etc/hosts
resolving <my_cluster_url>
to localhost
- In combination, these enable me to use the same SigV4Auth signing approach (with headers) that works from a within-VPC context to access the cluster from a Python script/Jupyter notebook
- https://docs.aws.amazon.com/neptune/latest/userguide/access-graph-gremlin-python.html
I have been trying to come up with an approach for handling the /etc/hosts
edit that doesn't require sudo
access or changes to system files. In principle, it should be possible to insert custom DNS resolution into the Python script, but I'm having no joy. Has anyone else previously hit and overcome this snag in this fashion/another way?Solution:Jump to solution
Ok, after a bit more tinkering, here's an implementation that doesn't require any outside-script configuration or tools, and doesn't require disabling SSL.
It requires an additional import
AiohttpTransport
which is used to pass the server hostname to DriverRemoteConnection
via transport_factory
, solving the hostname mismatch failure issue that arises without it by passing the 'correct' host to the TLS handshake.
```python...5 Replies
Have you thought of just doing all of this within a container? That way you could modify /etc/hosts in the container and not effect your workstation's config.
I hadn't, and that's an obvious-in-retrospect solution that leaves me somewhat kicking myself.
A third approach (that I had all the pieces for in my tinkering, just never all in the right place at the same time... thanks to https://github.com/awslabs/amazon-neptune-tools/tree/master/neptune-python-utils for completing the circuit) is as follows:
My understanding is that in this context
ssl=False
is not a security issue unless localhost
itself is somehow compromised, because the insecure portion of the traffic's journey is exclusively from the script making the request to the entrypoint to the SSM session tunnel at localhost:8182
SSL protects against man-in-the-middle attacks but also encrypts data sent between client and server to ensure any medium in which that traffic traverses is incapable of decrypting that data without the private key used in the creation of the server-side SSL cert.
Absolutely - ordinarily I wouldn't consider disabling it.
To be explicit, I am only considering this approach because I can assert that the journey from the development machine to the bastion host, to the Neptune cluster itself, is occurring exclusively through an AWS SSM Session, which is e2e encrypted using TLS.
I have now figured out a fourth approach using
dnspython
inside the script/notebook and coreDNS
via CLI, (which can be configured by files in the project directory, so is amenable to source control), which doesn't require setting ssl=False
I will edit this to share a minimal reproduction tomorrow 🙂Solution
Ok, after a bit more tinkering, here's an implementation that doesn't require any outside-script configuration or tools, and doesn't require disabling SSL.
It requires an additional import
AiohttpTransport
which is used to pass the server hostname to DriverRemoteConnection
via transport_factory
, solving the hostname mismatch failure issue that arises without it by passing the 'correct' host to the TLS handshake.