-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setup AWS VPN for database access #28
Comments
Hey team! Please add your planning poker estimate with ZenHub @patheard @sastels |
we might still want the jumpbox for non-db related things? @jimleroyer what else have we used it for? |
I've also used it for Redis access, but that could be setup with the VPN as well. |
VPN is installed from within the network, but restrict the access? We need to allow extra usage, unlike the jumpbox? Just wondering. (if we can still access Redis, that would certainly be helpful!) |
Yup, the way you set up the VPN is to grant it access to specific security groups, so in the case of Redis, we'd just need to allow the VPN traffic access to the EKS cluster security group: |
Please add your planning poker estimate with ZenHub @jzbahrai |
I was testing this yesterday when I discovered costing issues in Dev. I will resume testing today to ensure nothing is broken when this moves to staging. |
PR was approved, but I didn't merge at EOD. I will merge today. |
Note that the VPN adds $200/month in costing to each AWS account. |
Merged to staging. Need to test. |
Running into some DNS issues in dev. Debugging |
Will take a look at the DNS issues today. I've been working on the internal DNS (unrelated) and have put a PR here |
Did some more internal DNS refining yesterday. Switched nginx to an existing load balancer to better align with our releases. |
Ben is planning to roll out the Helm changes into staging this week. The migration only includes the Hasura utility and its dependencies, hence this is a relatively safe and incremental migration. |
Ben needs a review on this PR: |
Created two PRs for blazer. Will get reviewed today |
Refactored DNS to comply with Google OAuth requirements |
Blazer working in staging. Will put in a PR to move this to prod. |
Workflows added in prod, will test with next release. |
There is a PR for jump box but it wasn't approved yet. We will bring documentation, a script in the attic, to bring up an jump box instance on demand if we ever need to. |
Added documentation and debug pod script to notification-attic |
We just need to remove the jump box to get this card in qa. |
Merged, jump box manually removed in staging and prod |
@P0NDER0SA to QA |
QA nearly complete. All steps worked except for the fact that there is still a hasura pod. |
Description
As a developer,
I want a secure way to access the Notify database instance locally,
so that I can troubleshoot issues Notify data without worrying about unauthorized access to the data.
Acceptance Criteria** (Definition of done)
QA Steps
Additional context
We currently have hasura to audit the manually executed SQL statements in production by developers but it's limited in some ways:
notifications
table in its entirety (or dump the whole database to debug locally) is difficult with Hasura.Hence this card would increase the overall security on how we access the database.
The text was updated successfully, but these errors were encountered: