Page MenuHomePhabricator

Scap3 Service Restart Permissions
Closed, ResolvedPublic

Description

The method by which scap restarts a service:

  1. ssh into machine as a defined ssh_user
  2. that user calls: sudo service [service_name] restart

This user needs a sudoers rule:

[user] ALL=(root) NOPASSWD: /usr/sbin/service [service_name] restart

The private key for this user would reside on the deployment host (e.g. tin.eqiad.wmnet) and only be accessible via keyholder. Keyholder only allows folks in certain user-groups to access certain keys.

Citoid deploy setup as a concrete example:

  1. Create citoid-deploy group on tin and add citoid deployers to that group
  2. Add citoid-deploy private key to keyholder on deployment host
  3. Put the public ssh key (the private half of which was made accessible to the citoid-deploy group in the previous step) in the authorized_keys file for the citoid user on the citoid deployment targets
  4. Add sudoers rule to deployment targets: citoid ALL=(root) NOPASSWD: /usr/sbin/service citoid restart

This different from the way that trebuchet allows you to restart a service where everyone in wikidev can publish to the deploy.restart runner (https://github.com/wikimedia/operations-puppet/blob/production/modules/role/manifests/deployment/server.pp#L120)

Event Timeline

This was called out as a security concern in the deploy cabal meeting.

Certainly, this has security implications: lots of service users + sudo rules being added to targets; however, it seems like this is preferable to having anyone with access to tin being able to restart any deployed service.

mmodell moved this task from Needs triage to Debt on the Scap board.
thcipriani claimed this task.

This is largely dependent on how scap deploy ssh-permissions on setup. Closing unless there are further comments.