We have talked about this at Wikimania. There are some security-tools that have traditionally been running on a personal laptop and we want to move that to infrastructure. I have created a new dedicated ganeti VM for that purpose (see parent task) and a stub role. Darian will provide me with some scripts and i will puppetized them. We will put the scripts, minus passwords, in the public repo and the secrets in the private repo. Darian has existing deployment access and this new group will only be used on VMs dedicated to running security tools.

Change 296438 had a related patch set uploaded (by Dzahn):
admin: add new sectools-roots admin group

https://gerrit.wikimedia.org/r/296438

Change 296438 merged by Dzahn:
admin: add new sectools-roots admin group

https://gerrit.wikimedia.org/r/296438

Change 296651 had a related patch set uploaded (by Dzahn):
admin: add dpatrick to sectools-roots

https://gerrit.wikimedia.org/r/296651

It seems like this ought to be a foregone conclusion, ganeti instance for use by security person should allow root access by security person. But it's root access which normally means ops meeting. If anyone more senior on the team wants to weigh in, that would be great.

Neither this nor the subtask explain what exactly this VM will host and what Darian needs to run what and when — and why would this require full root.

Let's please get a little more clarity on this whole situation please (not just the access request)

@faindon OK, will ask for more info. @dpatrick what tools and scripts would this be running? What would you be using root for on the instance?

@faidon This is the outcome of meeting Darian at Wikimania. He has explained to me that there are some scripts that historically have been running on Chris' laptop and he would like to move them inside the infrastructure instead. I said we could offer him a Ganeti VM for that and that i'd be happy to help puppetizing the tools. Like removing secret credentials from scripts and putting them in the private repo while putting the public parts in the public repo. He was going to send the first script to me this week. Meanwhile i went ahead and created the VM with the stub role (to make sure it gets security upgrades etc) but waited with the access request itself to explain it in more detail.

OK. FTR, I would have prefered it if your meeting at Wikimania was transcribed into Phabricator on a separate task and if this work (puppet commits, fixing up the scripts to not hardcode credentials etc.) was staged before we handed out a prod VM. Seeing this all this staged into a separate code repository & Labs before we move into production would have been tremendously helpful.

In any case, from here onwards I'd propose:

• Let's see those scripts and some proper puppet role(s) on that machine first
• Check if they need superuser access (and why)
• Unless there are other compelling reasons, grant superuser access specifically to them

Ok, sorry for not leaving more detail. It was meant to be T138873#2412723 though and planned to explain it at meeting along with the access request. I just prepared the VM but did not hand out any access yet.

Any progress on this? @dpatrick: can we see the scripts?

Change 296651 abandoned by Dzahn:
admin: add dpatrick to sectools-roots, put group in role

Reason:
ticket is stalled

https://gerrit.wikimedia.org/r/296651

@dpatrick maybe we can get the scripts into puppet or a git repo at any rate as a first step?