Closed Bug 1388792 Opened 8 years ago Closed 7 years ago

Set up flows to new Gecko TC VPCs

Categories

(Taskcluster :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dustin, Unassigned)

References

Details

In bug 1387179, we're getting traffic flowing between these new VPCs and releng.scl3 and mdc1. Once that's in place, we need to define the flows. My understanding is that we want two flows: a. From AWS into the releng network to access the KMS server b. From the releng jumphosts into AWS for administrative access (ssh, rdp, vnc) I've set up an administrative subnet for flow (a). So my plan is: * fw.mdc1: all outbound traffic allowed, all inbound traffic forbidden * fw.releng.scl3: all outbound traffic allowed, all inbound traffic forbidden except admin subnet -> KMS server * workers configured with a security group allowing ssh/rdp/vnc from jumphosts (security groups are default-deny) A few questions remain: * what is the IP for the KMS server(s)? Port/proto? * what are the IPs for the releng jumphosts? * should any other hosts have admin access? I ask because releng team members do not have access to the releng jumphosts. * is it a design requirement that outbound access from mdc1 be restricted? If so, it's no bother to me but does mean that any changes to flows must be reconfigured in two places by two teams.
Flags: needinfo?(klibby)
correction: "I ask because taskcluster team members do not.." so basically confirming that the intent is only releng and buildduty folks will have ssh/rdp/vnc access.
> I've set up an administrative subnet for flow (a). So my plan is: > > * fw.mdc1: all outbound traffic allowed, all inbound traffic forbidden mdc1 is default-deny, including outbound traffic, so plan accordingly. > * what is the IP for the KMS server(s)? Port/proto? NI on Q > * what are the IPs for the releng jumphosts? rejh1.srv.releng.mdc1.mozilla.com has address 10.49.48.100 rejh2.srv.releng.mdc1.mozilla.com has address 10.49.48.101 rejh1.srv.releng.scl3.mozilla.com has address 10.26.48.19 rejh2.srv.releng.scl3.mozilla.com has address 10.26.48.20 > * should any other hosts have admin access? I ask because taskcluster team > members do not have access to the releng jumphosts. Uncertain. I think it's worth asking the question: if we're running TC within the data center, should the TC team have access? Amy? > * is it a design requirement that outbound access from mdc1 be restricted? > If so, it's no bother to me but does mean that any changes to flows must be > reconfigured in two places by two teams. Yes, it is.
Flags: needinfo?(q)
Flags: needinfo?(klibby)
Flags: needinfo?(arich)
The intent is releng+relops only and we can kill the host-based firewall (or apply a different security group) for taskcluster folks who need access. I'm sure that our support model for taskcluster is going to change in the future, and we'll revisit that then (or if we run into significant issues). KMS is port 1688 to kms1.ad.mozilla.com and (for future-proofing) kms02.ad.mozilla.com.
Flags: needinfo?(arich)
Flags: needinfo?(q)
[dmitchell@ssh1.corpdmz.scl3 ~]$ host kms1.ad.mozilla.com kms1.ad.mozilla.com has address 10.22.69.24 [dmitchell@ssh1.corpdmz.scl3 ~]$ host kms02.ad.mozilla.com kms02.ad.mozilla.com has address 10.48.69.100 The "default deny" in mdc1 is not default-deny - it allows at least VPN access. So it's not actually restricting who can access these hosts.
I *think* these flows are in place now. We are running lots of workers in these VPCs, so we can check that if desired. Note that the SG's on these workers do not have any special allowances for the rejh's -- my assumption is that you would add such SG's to specific instances when you want to access them. We can change that and create a 'rejh-admin' SG applied to all instances by default, if you'd prefer. Also note that the SG's on these workers do not limit outoging traffic -- we are relying on the Mozilla firewalls to protect the private network from access by the workers.
Looks like this is in place.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.