-
Notifications
You must be signed in to change notification settings - Fork 429
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
Postgres support for private_service_access #43
Postgres support for private_service_access #43
Conversation
This is taken as-is from the safer_mysql module. It's a way for this module to optionally depend upon the private_service_access module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dpetersen Thanks for the contribution. I've left a comment about this changes. Please take a look.
How is this PR looking? It's exactly what I'm waiting for (along with 0.12 changes) but it seems to have stalled |
On Postgres instances that are not passed the peering_completed ordering variable, there's no reason to set a label. This only sets the label (which is a necessary evil to ensure dependency ordering) in scenarios where it's required.
@aodj thank you for the reminder. I have been busy and let this slide. I just made the modifications that @namusyaka suggested and they seem to work as desired. Instances that aren't passed Thanks, everybody. Sorry for the delay. |
@dpetersen Amazing! |
I'm sorry for the late response. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change looks good. But considering the consistency for module design, I'm not sure if this change should be adopted into the postgresql
module. Extracting this change as new module (e.g. safer_postgresql
) is better, right?
@dpetersen @morgante What do you think?
I'm fine with directly adding it. |
I only really read the MySQL code enough to know what changes needed to be made to support private networking. I actually though the "safe" part was a reference to While using private networking on CloudSQL Postgres is probably safer than public, there are other reasons to prefer private networking: no need to configure a CloudSQL Proxy and lower latency from your VPC. The CloudSQL proxy feature was our primary motivation to run private instances, since the proxy as a sidecar container doesn't play well with Kubernetes Jobs. I think you'll want this change in this module regardless of whether you create a hardened |
Hmm OK. After migrating our modules into 0.12, we should be able to drop the change. |
I am trying to use the
postgresql
submodule with theprivate_service_access
submodule that was created as part of #35 for MySQL (really appreciate that work!). There's nothing inprivate_service_access
that's MySQL specific, but thepeering_completed
variable workaround to enforce dependency order was only added tosafer_mysql
.I also added a
private_address
output topostgresql
, trying to mirror the preexistinginstance_address
output. The README for the project says this works with a 1.12.x version of the google provider, butprivate_ip_address
wasn't introduced until version version 2.1.0. Does the README cover submodules, too? What's your policy on requiring a newer version of the provider?I tried to stick as closely as possible to naming and descriptions to what was already in the codebase. Let me know if you'd like anything changed. With these changes I was able to use private networking on our postgres instance, which is awesome. Thanks!