You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current approach used to do administrative connections and STAC operations in the database (if deployed in an isolated subnet) is to create a 'bastion host' (an ec2 instance) that lives in the same VPC as the database and is allowed to make connections to it, and create a tunnel from the user's local machine to that ec2 instance.
However, creating the tunnel is not a straightforward task at all, and even though we provide a good documentation for how to do it, it would be better to avoid that step. In addition to being complicated, one must make sure that her/his SSH public key is registered in the EC2 instance side. We have a 'user data' parameter for this in the bastion host construct, but I noticed that it doesn't work when updating a deployment. Overall, it's not easy.
The only reason we need this tunnel is make use of the local machine environment, in particular libraries to connect and interact with the database (e.g. on macos psql and then pypgstac for CLI-based record loading or STAC queries). If instead, we set up the ec2 instance environment so that it has all these tools, we could do away entirely with the tunnel, and, in the above mentioned case of a DB deployed in a private, isolated, subnet, a user willing to make administrative connections and interactions with the DB would just have one command to run :
aws ssm start-session --target $EC2_INSTANCE_ID
Once logged into the instance, the user can freely interact with the DB.
The text was updated successfully, but these errors were encountered:
emileten
changed the title
Add pypgstac and associated dependencies to bastion host environment
Support interacting directly with the database from the bastion host EC2 instance without a tunnel
Oct 12, 2023
The current approach used to do administrative connections and STAC operations in the database (if deployed in an isolated subnet) is to create a 'bastion host' (an ec2 instance) that lives in the same VPC as the database and is allowed to make connections to it, and create a tunnel from the user's local machine to that ec2 instance.
However, creating the tunnel is not a straightforward task at all, and even though we provide a good documentation for how to do it, it would be better to avoid that step. In addition to being complicated, one must make sure that her/his SSH public key is registered in the EC2 instance side. We have a 'user data' parameter for this in the bastion host construct, but I noticed that it doesn't work when updating a deployment. Overall, it's not easy.
The only reason we need this tunnel is make use of the local machine environment, in particular libraries to connect and interact with the database (e.g. on macos
psql
and thenpypgstac
for CLI-based record loading or STAC queries). If instead, we set up the ec2 instance environment so that it has all these tools, we could do away entirely with the tunnel, and, in the above mentioned case of a DB deployed in a private, isolated, subnet, a user willing to make administrative connections and interactions with the DB would just have one command to run :aws ssm start-session --target $EC2_INSTANCE_ID
Once logged into the instance, the user can freely interact with the DB.
The text was updated successfully, but these errors were encountered: