On Tue, 14 Jan 2014 16:09:05 -0700 Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Fri, 10 Jan 2014 11:09:16 -0700 > Tim Flink <tflink@xxxxxxxxxx> wrote: > > > For network isolation, I don't pretend to be an expert on networking > > so I'll describe the functionality that we're looking for and what I > > think might work for a solution, but I'll defer to the expertise > > here on whether it's a good idea or not :) > > > > The beaker and taskotron clients will need network access to several > > Fedora systems in order to work. > > > > Taskotron Clients: > > - Taskotron buildmaster > > - bodhi, koji, repos, dist-git, task-git (part of taskotron, not > > yet created), resultsdb (also part of taskotron) > > > > Beaker Clients: > > - Beaker server and lab controller (same system for now) > > - repos, maybe grabbing packages from koji/bodhi > > ok, and to be clear the koji/bodhi/dist-git is all public stuff > right? (ie, it could get it via public ip ok?) Yeah, it's all access to the public apis and URLs. > > I put together a quick diagram with the various network connections: > > http://tflink.fedorapeople.org/taskotron/client-network-connections.png > > Cool. All those arrows are bidirectional? Anything outside the box is not - the clients need to be able to access those resources but those resources do not need to be able to access the clients. > Are all the ones outside the box http/https? Yes. The only stuff that's not http/https is the connections from bastion, the beaker server and the taskotron master(s). The one thing that isn't part of that diagram is some sort of lockbox-ish host for managing and monitoring the clients. I'm still not sure how we want to configure all that (we had talked about putting everything but the clients in the infra playbook on lockbox01 and managing the clients with a different playbook on a different host but none of that has been done), though but I suspect that is one of the _simpler_ parts of the setup. > > From a few previous conversations, I think that a private network > > for the clients could provide the isolation that we're looking for. > > As far as getting network access to the systems needed to function, > > I figured that the beaker server and taskotron master would have > > network interfaces on this private network and a gateway could be > > used to restrict outgoing traffic to only the resources required. > > So, in some senses the 'qa' network is this. It's restricted from > talking to other internal stuff with some exceptions. > > Sadly over time, we have grown the number of things in that network > and of course all the stuff in that network can talk to each other > (barring local firewalls). Isn't that what usually happens to stuff like the qa network over time? :) > > All of the clients would be hosted on the qa virthosts, which are > > currently in the same rack. I was thinking that it would be possible > > to use one of the network interfaces in these virthosts to create > > this private network (assuming that the network switch capacity is > > available) but I'm definitely open to other ideas. > > Could we just do it with a private libvirt network on the qa > virthosts? ie, pick 172.31.17.0 and put them all in that and setup a > bastion host as their gateway that does NAT for them out to the stuff > they need. Or would NAT not work for this? They would still > physically be on the qa network tho, so I guess we could try and > request a real seperate one from RHIT. I'm not sure I understand this completely. Would this allow the various "special" hosts (beaker server and bastion host in particular) to connect to the clients without adding the step of "connect to virthostX" before being able to ssh into the clients? NAT should work for everything other than communication with the beaker server and bastion hosts. Another option might be to use ebtables. I haven't investigated this fully yet but it sounds like it would allow the use of qa network IPs but restrict the traffic running through the bridged network on the virthosts - effectively creating a restricted network without needing any physical changes. Of course, that would only work with VM clients but that's all we're planning for at the moment. > > Does this idea for network access and isolation seem reasonable and > > do-able? I figure that the network isolation/access part will > > require more discussion and time for implementation after a > > decision is reached. Our systems will work fine with the current > > network configuration but I wanted to get this part of the > > conversation started so that the implementation could happen before > > we get too far with automation development. > > Yeah, I think we can make something work here. > > There was also talk about redoing a lot of our network setup a while > back, but not sure where that went. The thought was to completely > seperate Fedora from anything else (which would be great), but would > require rework on a bunch of things. Once it's done however, we could > not have to care as much about adding new private nets, etc. That sounds like it would end up in a good place for isolating the clients but it also sounds like a lot of work. On the other hand, this "lull" between actively working on releases might be a "less bad" time to do major changes like that but I'll refrain from commenting more on it since I'd likely not be the one doing all the work. Tim
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
