As a prelude to removing full root access for CI folks from scandium (contint-root), they will need to slightly expand the rights of contint-admins.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| contint: grant zuul-merger sudo rules | operations/puppet | production | +6 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | hashar | T70480 Scale merge operations (tracking) | |||
| Resolved | hashar | T95046 install/deploy scandium as zuul merger (ci) server | |||
| Resolved | hashar | T116921 Remove CI root access from scandium | |||
| Resolved | Andrew | T119526 Give contint-admins sudo rights to start/stop zuul-merger |
Event Timeline
Comment Actions
Change 254129 had a related patch set uploaded (by Andrew Bogott):
contint: grant zuul-merger sudo rules
Comment Actions
I suppose as this is a sudo rights ticket it will have to be discussed at the ops meeting. However I'm for it, yesterday even. Is there anyone with contint-admins who gets more access due to this?
Comment Actions
The historical zuul-merger instance is on gallium a Precise system. There we have sudo access as user zuul via:
ALL = (zuul) NOPASSWD: ALL
That let us manage the service with something like: sudo -u zuul /etc/init.d/zuul-merger stop.
The new instance runs on scandium which is a Jessie system and wraps init scripts with systemd which requires root. So the root sudo commands are merely to let us interact with the zuul-merger via systemd.
Maybe systemd as a way to mention a given user has super rights on a given service, but I haven't found any evidence of such feature. Seems everything has to be done by root :-/
Note journalctl is problematic, it has a bunch of super useful options but accepting a wildcard in the sudo rule would probably lead to some escalated privilege. I lack good knowledge and time to review the sudo doc, so I played it safe and explicitly defined the full command which is good enough for our usage:
ALL = NOPASSWD: /bin/journalctl -u zuul-merger
So in short, no different privileges are being applied beside maybe journalctl.
Comment Actions
If this is problematic then it would be problematic for a lot of other services too.
We do 'ALL = NOPASSWD: /bin/journalctl *' in a lot of admin roles.
Comment Actions
Well let's discuss it today at the ops meeting and assuming no one minds then it will be on the record for the future too.
Comment Actions
I amended the change and merged it.
re: journalctl. amended this for consistency with other services, we tried before to limit this to a specific unit but that either doesn't work or is not an actual limitation. see also https://gerrit.wikimedia.org/r/#/c/251714/ and the tickets about tilerator access
ran puppet on gallium:
root@gallium:/etc/sudoers.d# cat contint-admins # This file is managed by Puppet! %contint-admins ALL = (jenkins) NOPASSWD: ALL %contint-admins ALL = (jenkins-slave) NOPASSWD: ALL %contint-admins ALL = (gerritslave) NOPASSWD: ALL %contint-admins ALL = (nodepool) NOPASSWD: ALL %contint-admins ALL = (zuul) NOPASSWD: ALL %contint-admins ALL = NOPASSWD: /etc/init.d/jenkins %contint-admins ALL = NOPASSWD: /etc/init.d/postgresql-8.4 %contint-admins ALL = NOPASSWD: /usr/sbin/service nodepool start %contint-admins ALL = NOPASSWD: /usr/sbin/service nodepool stop %contint-admins ALL = NOPASSWD: /usr/sbin/service nodepool status %contint-admins ALL = NOPASSWD: /usr/sbin/service zuul-merger reload %contint-admins ALL = NOPASSWD: /usr/sbin/service zuul-merger restart %contint-admins ALL = NOPASSWD: /usr/sbin/service zuul-merger start %contint-admins ALL = NOPASSWD: /usr/sbin/service zuul-merger stop %contint-admins ALL = NOPASSWD: /usr/sbin/service zuul-merger status %contint-admins ALL = NOPASSWD: /bin/journalctl* %contint-admins ALL = NOPASSWD: /usr/local/sbin/puppet-run %contint-admins ALL = (postgres) NOPASSWD: /usr/bin/psql