QA Client Network Isolation and FAS Groups

Tim Flink tflink at redhat.com
Fri Jan 10 18:09:16 UTC 2014


One of the things that QA is focusing on ATM is getting better
automation support for Fedora. We're currently doing this in two ways
(that will eventually combine):

 - taskotron (replacing autoqa)
 - beaker (different type of system - used by Red Hat QE, who is
   interested in running some of their tests upstream in Fedora)

Before we start granting access to the systems to Fedora contributors,
we want to a) make the process relatively easy and b) isolate the
client machines so that if something goes wrong or a bad actor gains
access to them, any potential problems can be limited.

To do this, I'd like to propose one change and ask for input on another.

The first change is with FAS groups and shell access. To the best of my
knowledge, in order to ssh into the bastion hosts, a user needs to be a
member of the sysadmin group. While this works well for sysadmin
people, I'm not sure I see a benefit of sending all sysadmin email to
folks who are just looking to debug beaker or taskotron clients. I'd
like to propose the creation of a new FAS shell group for qa automation
and separate groups for beaker users, beaker admins, taskotron users
and taskotron admins (qa-automation, beaker, beaker-admin, taskotron,
taskotron-admin).

The qa-automation group wouldn't need access to bastion01, just
whichever bastion host has access to the automation clients
(bastion-comm01 for now). The other groups would be kind of like the
relationship between the various sysadmin FAS groups and the base
sysadmin group (ie, sysadmin access for all members, sysadmin-dns,
sysadmin-qa etc. for farther access).

Does this seem reasonable and do-able? If so, I'd like to get the FAS
group stuff done in the relatively near future - not "drop everything
and do it now" but ideally in the next couple of weeks if possible.

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

I put together a quick diagram with the various network connections:
http://tflink.fedorapeople.org/taskotron/client-network-connections.png

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.

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.

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.

Thanks,

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20140110/19adb41a/attachment.sig>


More information about the infrastructure mailing list