- add to wmf LDAP group
- add to ops LDAP group
- gerrit login
- +2 on operations/puppet
- phabricator login (@Mathew.onipe)
- phabricator permissions to see NDA and Ops restricted tickets
- shell user (connecting to bastions)
- server root shell (on relforge/elasticsearch hosts)
- add to private IRC channels
- add to ops mailing lists
- add to exim mail aliases
- icinga login (this is auto-solved by the "add to wmf LDAP group" part which also gives a lot more logins listed at https://wikitech.wikimedia.org/wiki/LDAP/Groups#Specific_groups)
- icinga user and permissions (icinga commands, paging/notifications)
- access to pwstore
It is not entirely clear what access we want to give @Mathew.onipe at this point.
- Matt is a contractor with a more junior profile than our usual Opsen
- We need Matt to be able to work on at least elasticsearch and wdqs clusters, including the reimaging those clusters
- Our current flat model is reaching its limit, is now the right time to think about changing it (without blocking Matt from working while we change it)
We have used wmcs-roots to grant a subset of roles to particular users who really only operate within the context of cloud services and it has seemed to work well. If we created a search-roots (or something) and applied it to a handful of roles it seems like this may be sufficient? This isn't me objecting to adding this user to the broader ops group, but it sounds like some smaller scope may be appropriate if it's reasonably practical to achieve in this case for now. It would be fairly quick/easy to create.
Summarizing a few back channel conversations here:
- the current thinking is to start by giving @Mathew.onipe a few already existing roles (elasticsearch-roots, wdqs-admins)
- there are a few operations where we don't have good ways to restrict access by cluster (reimaging servers, access to remote management consoles, ...), so at some point we'll need to provide larger accesses
- while @Mathew.onipe has less experience than most our SRE he has experience working on production infrastructure
Access to remote management consoles only needs bastion access and having the mgmt password.
The datacenter-ops admin group allows running puppet and install-console which allows for reimaging servers.
If we expect that at some point Matt will do general ops work for us (example: clinic duty), we want to make sure there is a path forward that provides him with the access to do that. Or decide to give such access now. I don't think the matter of his being 'junior' is at issue; do we trust him to be careful as a root user? Has he had root on a production cluster in his previous ops-related work? I understand the answer to the last question is 'yes'. Does he have the requisite knowledge to be careful? Again my understanding from irc chats is that the answer to that question is yes.
Added to "wmf" LDAP group, which gives these permissions, including Icinga:
"ops" LDAP group is separate though since that needs to match the shell access group which is still pending, hence i made it a separate checkbox
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzc2xF3S5UnIFMnK0gbGBhYvsN+xjiJejtEZUnGb23vJTX7N955C7dBdHkTHpcV7+yWqpzzWkJCpnRs5Q0P+JyQ5hOikv7WrKcsjIODuUpMzkRIlWzmGwuA6fXvJqAcyqSdXeQAAczUnlItMl0BB0L0LsB5xY7aqkt0atm1CPkQcFKBc90KJiW8Tkuh5MiYIXe18o+mCI/Q+yPfUxaqQZ0rp9pmFk1L021D3BL7YNpTZYSwbulnxc/y++VD1Ot/2kmCX2HhB9APVP36VZwqDcb+Ik2ZMsrtxIBz2qQjsbUnZvS9rqqJrF8MQhLmfe/M1gK8pbR0yV8DXHSSG3uJ1Db matt@matt
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDn/YXPi5kmu067j+YF5sSDkdH7+YDtu4aT5I58IREQmWqMzOj5zpIdbIGsEeP5wGJimqE9SQD9vokS8jO5H/d+3ZSZz1qU2lU1cmx6CHDm7vL/tOPgBgscn4TipvX1XkQ8CfEBddVe5jL9Y3GLX5EgxuNFXsMmpE8KpHQ/nSmOoxVIDAeqFgfNJSHccw7PyqVjZIdxmmU4hYq4KtcmnrETHJ6SPFigzR+J4kMAq97/9+LxY68vwzbhQF1O2yHmTLASrxIg2vQaI07d8+5N6lewmwXPt++Bkg8pT4IZOdNn24YtiBceK3Zi0w1Yki5H3tPTkppfk2GSaxROmyvFdoWt matt@matt
Thanks @Dzahn to move this forward! I was stalling this for too long.
For the next steps:
- I'll propose adding @Mathew.onipe to elasticsearch-roots and wdqs-admins during next ops weekly
- I propose to wait until @Mathew.onipe has worked on a few puppet patches before giving him +2 on puppet
- I propose to wait until we have an actual need to give him access to pwstore
@Mathew.onipe is not blocked by this in his current work, so let's not rush things more than we need.
To the best of my knowledge this is resolved now.
We went through the Icinga part and added permissions and confirmed they work.
I updated the checkboxes that were already done and clarified (ssh to bastions, ssh and root on elastic/relforge). Matt confirmed he can get root on elastic and relforge machines.
The remaining boxes have been declined for not being needed for now.
The former comments from Gehel also confirm this and i see it was moved to a "Done" column, so resolving it here as well. Let me know if i'm missing anything. Matt also said he is good for now and would open a new ticket if he runs into something blocking him.