Username: kharlan
Full name: Kosta Harlan
Follow up from T203847: Requesting access to researchers for kharlan, I'd like to be able to ssh to production servers for the purposes of viewing logs and debugging in production to diagnose and troubleshoot issues that are not reproducible otherwise.
Since the request is specifically for viewing logs i recommend using the group "mw-log-readers" which was made for this purpose.
It gives access to mwlog*
gid: 760 description: users who can login on mwlog hosts and read mediawiki logs
The link to docs about debugging mentions mwmaint1002. We should add the group to that role then. It makes sense. More so than using "restricted" for this which also has sudo privileges to run any command as www-data and apache which doesn't seem to be needed/requested. Not asking for these extra sudo privileges also means this ticket can be processed without having to be brought up in SRE meeting.
I saw we also have "maintenance-log-readers". It allows for access to mwmaint* hosts and reading logs (includes running journcalctl, dmesg, anything as syslog user).
gid: 799 description: People who can read syslog and dmesg on mediawiki maintenance servers
So this should do it, i recommend the combination of mw-log-readers and maintenance-log-readers and we don't have to make changes to any roles.
Ok. The need for "sudo as www-data" wasn't obvious to me from the request or the linked wikitech page. I see it when looking at actual mwrepl source though.
Indeed "restricted" is the closest thing we have then unless we make changes.
I think the idea is to prevent/dissuade people running mediawiki code under higher privileged accounts e.g. deployers/ops that could have access to other things.
btw, I'm still not convinced about the rules regarding sudo review in access requests. Some groups give users permissions just based on the files they can access (e.g. the shared mysql password that researchers can read off the filesystem), some based on keyholder auth (to determine whether you can ssh out to some host with certain shared credentials it looks at your local groups), and these don't necessarily trigger meeting review. Meanwhile we have sudo rules that allow you to become a lower privileged account (e.g. sudo from deployers/restricted down to www-data), and these do trigger meeting review. Plus we have people opening access requests who only say which hosts they want to SSH to but not what kind of access they want when they get there (which is the most important part imho).
You might as well give kosta restricted. He's starting deployment training and will probably be requesting deployment by the end of the year. In other words, whatever group you assign him to is only going to be temporary anyway.
Change 468327 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/puppet@production] admins: add kharlan to 'restricted' group
Change 468327 merged by Effie Mouzeli:
[operations/puppet@production] admins: add kharlan to 'restricted' group
@kostajh : You're using the same key in production as in WMCS: This is a security risk since WMCS allows SSH agent forwarding and a malicious privileged user in WMCS can connect to your forwarded agent socket and connect to production on your behalf.
Please create a new SSH key for production access and paste the public key to this task.
@MoritzMuehlenhoff I'm sorry about that. Here's the new public key:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHZqJOizHso9YldV5FMsnoJnWfLIno11qlXjVGfSBWb5 kharlan@wikimedia.org
Change 469884 had a related patch set uploaded (by Effie Mouzeli; owner: Effie Mouzeli):
[operations/puppet@production] admin: Updated key for kharlan
Change 469884 merged by Effie Mouzeli:
[operations/puppet@production] admin: Updated key for kharlan