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
{{ message }}
This repository has been archived by the owner on Sep 16, 2020. It is now read-only.
I'd like to remove this bit of code from the external SQL:
authorized_networks = [ { name = "all" value = "0.0.0.0/0" }, ]
There are a few ways to do this. First is that we should create NAT instances for externally bound traffic. This implies other changes. Secondly we could wait until Cloud SQL can do internal IPs and fix it then. Opening this for discussion.
The text was updated successfully, but these errors were encountered:
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.
The labels on this github issue will be updated when the story is started.
If we do this we should use NAT GWs and not NAT Instances - but I don't believe they are as yet doable with terraform. (Also NAT GWs are also still in beta)
Perhaps by EOY we can re-evaluate both of these conditions. My preference would be do to both, default SQL to Private IP and yet also add optional NAT GWs.
@matthewfischer - can we try working in the private IPs first and then when NAT GWs become a thing introducing those? Seems like at least the Private IPs would be more secure in the short term.
I'd like to remove this bit of code from the external SQL:
authorized_networks = [ { name = "all" value = "0.0.0.0/0" }, ]
There are a few ways to do this. First is that we should create NAT instances for externally bound traffic. This implies other changes. Secondly we could wait until Cloud SQL can do internal IPs and fix it then. Opening this for discussion.
The text was updated successfully, but these errors were encountered: