[tech] Fwd: Gitlab CI for ucc-fw & introducing wheel-runner

[James Arcus]

Oops, this should have gone to tech@ so everyone who is interested can 
be aware.

Cheers,

James [MPT]



-------- Forwarded Message --------
Subject: 	Gitlab CI for ucc-fw & introducing wheel-runner
Date: 	Wed, 30 Jun 2021 05:25:45 +0800
From: 	James Arcus <jimbo at ucc.asn.au>
To: 	wheel at ucc.asn.au <wheel at ucc.asn.au>



Hi all,

After being inspired by discussion on Monday night and being cooped up 
awaiting my COVID test results, I decided to have a hack at getting the 
firewall script to be deployed by Gitlab CI. I appear to have succeeded!

While ucc-fw has been in Gitlab for a while now, it was previously just 
a mirror driven by changes made by root locally. It's now the other way 
around, with murasoi being prompted to pull from Gitlab whenever changes 
are made to master. The hope is that this way, asking for a firewall 
change can become more of an active process for any members who are 
interested but who aren't on wheel.

To facilitate the CI/CD job, I've spun up a new Debian machine named 
wheel-runner with the Gitlab Runner software installed. Right now this 
is the only thing it handles, but I'm imagining in future it will be 
able to handle more configuration deployments for other parts of the 
network, like DHCP or DNS. It can also be assigned to CI jobs for other 
UCC repos, but I believe it'd be best to not use it to run untrusted code.

The relevant moving parts of interest are the Gitlab CI config at 
https://gitlab.ucc.asn.au/ucc-configuration/ucc-fw/-/blob/master/.gitlab-ci.yml, 
and the sudoers file along with /usr/local/bin/pull-fw.sh on murasoi. 
Instead of having the runner drop the firewall script (which is then 
executed by root) onto murasoi directly, it instead prompts murasoi to 
pull an updated copy from the upstream repo separately. That way, a 
compromise to the deploy at murasoi account or the runner doesn't mean an 
automatic privilege escalation.

I've never written a CI job before, so I'm sure there are neater and 
better ways to do what I've done. Improvements are welcome! Right now 
the next thing I want to do is remove the need for 
StrictHostKeyChecking=no in the CI pipeline.

Cheers,

James [MPT]

P.S. for those of you receiving them, sorry for all the "Failed 
pipeline" emails that I generated trying to get things working.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20210718/38b2c937/attachment.htm>