Hello Chase! I hope all is well with you and yours. I have a couple of questions about networking which you may or may not have opinions or thoughts about :)
We've been butting our heads against the inability of VMs in the -dev cloud to talk to outside networks. When Jason and Arturo looked at ways to open that up, they ran into several code comments from you expressing unspecific worries about security concerns with allowing that traffic. Do you remember what those concerns were? If it was just a matter of 'we don't need this anyway' then we might go ahead and allow that traffic, but I want to make sure we aren't overlooking some grave danger.
Related to that -- it's clear that in the past there was an apt proxy running someplace to allow labtest VMs to connect to apt repos. Do you remember how that proxy was set up? I think it must not have been puppetized because I can't find any traces of it in the git history for the box it was surely running on. (Obviously this is moot if we open up the routing.)
Thanks!
-A
On 11/12/19 5:36 PM, Andrew Bogott wrote:
We've been butting our heads against the inability of VMs in the -dev cloud to talk to outside networks. When Jason and Arturo looked at ways to open that up, they ran into several code comments from you expressing unspecific worries about security concerns with allowing that traffic. Do you remember what those concerns were? If it was just a matter of 'we don't need this anyway' then we might go ahead and allow that traffic, but I want to make sure we aren't overlooking some grave danger.
I think we can move forward with this change and re-consider things in case we see any issue later on.
I believe it's really important eqiad1 and codfw1dev are very similar in architecture, features and behavior so we can use the staging/dev/test environment effectively.
I'm not 100% sure how LDAP works for the codfw1dev deployment, but I would double check that we don't leak anything to the outside. Special consideration for cases like internet --> VM in codfw1dev (some proxy, redirection or floating IP can enable this).
regards.
So if I recall correctly, and this may be hopelessly outdated arcane information from 3+ years ago at this point, historically the labtest realm had access to the production private network (and in fact the only way to SSH in was by using production hosts as a bastion), and this may have been a solution to that.
On Tue, 12 Nov 2019 at 16:37, Andrew Bogott abogott@wikimedia.org wrote:
Hello Chase! I hope all is well with you and yours. I have a couple of questions about networking which you may or may not have opinions or thoughts about :)
We've been butting our heads against the inability of VMs in the -dev cloud to talk to outside networks. When Jason and Arturo looked at ways to open that up, they ran into several code comments from you expressing unspecific worries about security concerns with allowing that traffic. Do you remember what those concerns were? If it was just a matter of 'we don't need this anyway' then we might go ahead and allow that traffic, but I want to make sure we aren't overlooking some grave danger.
Related to that -- it's clear that in the past there was an apt proxy running someplace to allow labtest VMs to connect to apt repos. Do you remember how that proxy was set up? I think it must not have been puppetized because I can't find any traces of it in the git history for the box it was surely running on. (Obviously this is moot if we open up the routing.)
Thanks!
-A
Cloud-admin mailing list Cloud-admin@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/cloud-admin
On 11/26/19 1:43 AM, Alex Monk wrote:
So if I recall correctly, and this may be hopelessly outdated arcane information from 3+ years ago at this point, historically the labtest realm had access to the production private network (and in fact the only way to SSH in was by using production hosts as a bastion), and this may have been a solution to that.
That makes sense, thanks.
I think we can replicate the model we have in eqiad1: create a bastion VM.
This should be also a good excessive for some newer folks in our environment, it allows to learn how CloudVPS works in general, and replicate the setup in codfw1dev.
regards-
cloud-admin@lists.wikimedia.org